Two people can run one game, and a game can change hands

[HarryCordewener]

§8.5 allows a game several owners, each having verified a token of their own. §8.4 makes a counter-claim — a different account proving control now — the way a game changes hands. Both were in the spec, claim_event's vocabulary already contained counter_claimed, and nothing could reach either.

Stacked on #32 (feat/claim-wiring), which registers IClaimStore and makes the dashboard able to read claims at all.

The fact the whole design turns on

A co-founder joining and a new operator taking over publish the identical line in the identical config file. The crawler reads the same string either way. The difference cannot be measured, so it is declared — by the claimant, on a page that explains both, before the token is minted, and stored on the claim that token belongs to.

Guessing was the alternative, and it is wrong in both directions:

• "A claim on an already-claimed game is a takeover" silently unclaims somebody's partner the first time two people run one game.
• The opposite leaves a departed operator holding a listing they no longer run.

Neither intent is more trusted. Both publish a token on the server, which is the whole test (§8.1) — so an account choosing assume has proved exactly what one choosing join proved. The choice decides what happens to the other claims, not how hard this one was to make. That is why storing it at issue time matters: a token published as a co-owner must not be settleable as a takeover.

What a counter-claim does

It revokes the displaced owners, and it is the one revocation nobody typed. Three things follow, all asserted:

• The event goes on the losing claim. That is whose record changed. An owner who finds their claim gone must be able to read why from their own history rather than inferring it from somebody else's.
• The game never stops being claimed on the way through, so a handover does not flicker the listing badge off and on.
• The displaced owner's token still settles nothing. It is very likely still in the config file — that is the normal state of a handover — and every probe reads it. Presence establishes and absence never revokes (§8.4), but a revoked claim is not a claim.

Resigning

Explicit, as §8.4 requires of every revocation that is not a counter-claim: a claim never lapses on its own.

RevokeAsync takes a claim id and nothing else, which is right for the service and wrong for a caller reached from a form — a claim id is not a credential and travels in URLs and logs. ResignAsync checks the claim belongs to the account. The form asks for the word typed out, because a bare button beside a game's name is one misclick from a listing an operator no longer owns.

The last owner leaving unclaims the game; anyone else leaving does not. Nothing is deleted: the claim survives revoked, with its reason and its history.

The audit log, in words

The dashboard names co-owners and renders each claim's history. BeaconMissing reads as an observation rather than a warning — a probe not reading the token happens for reasons nothing to do with the owner, and alarming them about it would be the interface arguing for a rule the system does not have.

Migration

0012_claim_intent.sql — expect to renumber; 0009 is taken twice (#31, #30), 0010 by #21 and 0011 by #28. The column defaults to join, which is the honest backfill: no claim written before it existed displaced anybody, so recording them as joins states what happened rather than inventing an intent nobody expressed.

The dashboard is rendered now, and it was greeting owners with a variable name

Account.razor had no render harness on any branch while five features' worth of markup landed in it across this chain — the owner panel, the scorecard link, the badge snippet, the co-owner line, the history block, the resign form and the status banner. The first render found a bug in the first line it produced:

<h3>What only you can tell us about game.Name</h3>

A component parameter of type string written as Name="game.Name" is a literal, not an expression. GameId="game.Id" immediately above it is parsed as an expression, because Guid is not a string — which is exactly what hid it. The two lines look identical and only one of them was wrong. Every owner would have been greeted by the name of a variable.

States covered

No database · signed out · signed in with nothing claimed · a pending claim · a verified claim with everything a claim grants (§8.5 enrichment, §11 suppression, the scorecard link, the badge snippet, the audit log, §8.4 resignation) · several games at once · a co-owned game, where the resign copy differs.

The status banner

Driven through every arm of its else-if chain by the querystring the redirect actually carries, plus a crafted URL carrying three outcomes at once to pin which arm wins. This page has already told an operator the wrong thing once — hiding a connect screen reported the enrichment sentence — and #35 gave the chain a third arm. A chain is the shape that silently reports the wrong branch.

Two things pinned that had gone wrong before

Every form action is checked against the routes the deployable actually maps. A form posting to an unmapped route fails at the browser, not at build: no compiler, renderer or unit test says a word. Verified by typo-ing an action and watching the test name it. (This needed reading the routes off the builder — the composite EndpointDataSource in DI is empty until the app starts, so resolving it there would have compared the page against no routes and passed for the wrong reason.)

The badge snippet is checked as entity-encoded bytes. It is correct — <img src="…" — but the assertion output HTML-decodes what it prints, which made correctly escaped markup look like markup that had got away. Read off the rendered bytes instead.

On authentication, since it is the thing being tested

The signed-out and no-database states go through SiteHost end to end. The signed-in states cannot: §8.2 makes passkeys the only way in, so a loopback host has no way to produce an authenticated session without an authenticator. Those render at component level with an HttpContext cascaded in — which is the object the framework would have supplied, so the page's own guard on Identity.IsAuthenticated still runs and the claims it filters are real records in a real ClaimService. What stands in is the user store and the credential ceremony, neither of which is the authorisation under test. Saying so rather than quietly stubbing it.

One incidental finding: [SupplyParameterFromQuery] does not bind under a bare HtmlRenderer unless AddSupplyValueFromQueryProvider() is registered. Without it every one of those properties is null and the banner silently never renders — indistinguishable from a banner that decided not to.

Verified

dotnet build MUIndex.slnx -c Release clean, each suite run directly — 1,192 tests, 0 failed (the chain, not this branch alone):

suite	total
MUI.Catalog.Tests	297
MUI.Crawl.Tests	142
MUI.Crawler.Tests	154
MUI.Discovery.Tests	255
MUI.Web.Tests	344

Catalog and Crawler against real PostgreSQL via Testcontainers/Podman. 13 new tests, including both directions of the intent vocabulary against the real CHECK constraint — a constraint that refuses a value the code produces does not fail in a test, it fails the first time somebody tries to take over a game.

Left undone

• No notification to a displaced owner. There is no channel: §8.2 stores no email by design. They see it in their dashboard history, which is the only place we can tell them.
• No staff arbitration. Two accounts with server access can counter-claim each other indefinitely; the last one to publish wins. That is the same property §8.1 already has and it is correct — control of the server is the claim — but it is worth naming.
• Account.razor and Claim.razor will conflict with Owning a game: add what MSSP has no field for, and take your screen back #29, Read an operator their own MSSP back, and never call it a fault #33 and A badge that would rather say nothing than say nought #34, all of which touch these files.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4a52579e-ffd4-4d99-ad90-62275f609cfd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[HarryCordewener]

CI does not run on PRs whose base is not main, so the checks tab here is empty. Dispatched the same workflow against the branch instead — green on both legs: https://github.com/SharpMUSH/MUIndex/actions/runs/31869718543

Re-target to main once #32 lands and the checks will attach normally.

[HarryCordewener]

@coderabbitai review

[coderabbitai]

⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.