P0: a real Anthropic key is refused when spawning a forge — accept any key as pasted (cherry-pick steward/model-key-accept) #7552

P0: the owner cannot add a real Anthropic API key when spawning a forge. It fails with "must be one line with no spaces…". The check refused any whitespace inside the key, so a wrapped line or an invisible space from the paste is enough to reject a real key. The owner: "these need to be accepted. remove the overbearing string analysis and just accept anything. what about when i build my own ai gateway and have my own structure??"

The fix is written and tested on branch steward/model-key-accept in this repository, commit e33b1de0:

• normalizeToken (src/core/subscriptions.ts) drops every whitespace character (including NBSP and zero-width) and a leading Bearer .
• kindOfToken accepts any non-empty key up to 4096 characters, of any shape (own gateways).
• The spawn action, the door and the subscription pool all store the normalized key.
• The only refusal left is "is empty".
• Tests updated: wrapped, trailing-newline, Bearer-prefixed and gateway keys are accepted, and blank or zero-width-only keys are refused. new-forge, spawn-keys, spawn-anon and subscriptions: 48 pass. tsc is clean.

Do: from your fork, fetch steward/launch-no-tla's sibling branch steward/model-key-accept, cherry-pick e33b1de0 onto main, run bun test test/subscriptions.test.ts test/spawn-keys.test.ts test/new-forge.test.ts test/spawn-anon.test.ts, and open the pull. Land it as written.

Live triage (automatic, not written by a person): filed under P0 Trust, which it names.

Parked by the crew: the check failed ("verify an email from the People screen > an admin verifies the person under the cursor and the row changes") and the decider saw no point in another try try 1: src/actions/spawn.ts, src/core/subscriptions.ts, src/spawn/door.ts, test/new-forge.test.ts (+2 more) try 2: src/actions/spawn.ts, src/core/subscriptions.ts (pull #7563 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check failed ("MCP subscription_add > a bad token is refused with the page's words") and the decider saw no point in another try try 1: src/actions/spawn.ts, src/core/subscriptions.ts, src/spawn/door.ts, test/new-forge.test.ts (+2 more) (pull #7602 closed).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check failed ("verify an email from the People screen > an admin verifies the person under the cursor and the row changes") and the decider saw no point in another try try 1: src/actions/spawn.ts, src/core/subscriptions.ts, src/spawn/door.ts, test/new-forge.test.ts (+2 more) try 2: src/actions/spawn.ts, src/core/subscriptions.ts (pull #7563 closed)
2. the check failed ("MCP subscription_add > a bad token is refused with the page's words") and the decider saw no point in another try try 1: src/actions/spawn.ts, src/core/subscriptions.ts, src/spawn/door.ts, test/new-forge.test.ts (+2 more) (pull #7602 closed)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Planner: replaced by #7628. The reds were not in the change. One was test/mcp-subscription-add.test.ts, whose "bad token" is "not a token": valid once any key is accepted, so that test must send a blank key. The other was the order-dependent People-screen verify test (#7599). #7628 says both, and lands e33b1de0 as written.