The theory lesson explained what a bearer token is. This lab mints a real, scoped Fire token, watches it succeed exactly where its abilities say it should, and watches it fail — loudly, identically to no token at all — the moment it's asked to do something outside that scope.
Theory 1 of 2
Minting is a separate act from using.
A token gets created once, via fire:token, with an explicit list of abilities chosen at that moment — not inferred later from what you happen to try. Everything after minting is just that string, sent on every request. There's no step where the system asks "did you mean to be allowed to do this" — the abilities list was the only place that question ever got answered.
Theory 2 of 2
Wrong scope and no token look identical from the outside.
Fire's real error codes don't have a separate "your token exists but can't do this" response — a scope mismatch returns the same 401 AUTH_FAILURE as a missing header. That's not a bug to work around; it's worth knowing going in, so a valid-looking failure doesn't send you hunting for a typo that was never there.
Before the Practicum
One token, minted twice, two different scopes.
Same terminal as every other lab — click it, type or paste the command shown, Enter runs it.
fire:token is the real minting command from this project's own boot file — --abilities takes a comma-separated list.
Every call after minting targets Fire's real test host, https://fire.test1.prosaga.net, exactly as documented in API.md.
Done
The token never changed. Only what it was allowed to do did.
Same shape, fire_sk_ plus 40 characters, both times. The first one worked for status and failed identically to having nothing at all for chat. The second worked for chat because — and only because — chat was on its list at the moment it was minted. Scope isn't a suggestion the server tries to honor. It's the entire content of what the token means.