DOCS/ENGINE.MD
The Engine Dashboard
!gf engine is a bot-wide, cross-server dashboard for whoever actually
runs the bot - not a per-server admin tool. It shows things a single
server's admin shouldn't be able to see about other servers (which
server is busiest, bot-wide AI usage, a live feed of what's happening
everywhere), so it has its own, separate permission model from every other
command.
It is deliberately not listed in !gf help or docs/COMMANDS.md's
in-Discord command table - a random server admin shouldn't even know it
exists. You're expected to learn about it from this page.
Who can use it
Two independent checks, not one:
isOwner(userId)- you must be listed inoptions.ownerswhen you constructGlassFrame. This is required, full stop, for the command itself and every page-navigation button click afterward.- A password (optional) - if
config.engine.passwordis set, the initial!gf engine <password>command also needs the correct password. Page-navigation button clicks after that don't re-prompt for it, since a button click is already tied to a real, verified Discord identity - only the text-command entry point needs the second factor.
const frame = new GlassFrame(client, {
getLogChannel: /* ... */,
owners: ["your-discord-user-id"],
config: {
engine: {
password: process.env.GLASSFRAME_ENGINE_PASSWORD // never hardcode a real one
}
}
});
Leave config.engine.password unset to skip the second factor and rely on
the owners list alone.
What happens to the password
Typing a password into a normal Discord message means it briefly sits in plain text in a channel, visible to anyone watching and to Discord's own message history. GlassFrame does two things about that:
- The command message is deleted immediately after being checked, whether the password was right or wrong.
- Wrong guesses count toward a lockout -
config.engine.maxAttemptswrong attempts (default 3) locks that user out forconfig.engine.lockoutMs(default 10 minutes), making brute-forcing impractical.
Use a private channel (or a channel only you can see) for this command regardless - deletion happens right after Discord delivers the message, not before anyone in the channel could have glimpsed it.
The five pages
One row of tab buttons switches between them; the active tab is highlighted.
| Page | Shows |
|---|---|
| Overview | Version, uptime, guild count, layer adoption across every server |
| Servers | The busiest servers ranked by event volume since this process started |
| AI | Groq key pool status, cooldowns, call volume, verdict cache hit rate |
| Performance | Action/AI queue depth, all three cache stats, average latency per operation |
| Activity Log | The last several things logged anywhere, any server, newest first |
All of it comes from one call: frame.getEngineReport(), if you want the
raw data instead of the rendered message (for your own dashboard, an API
endpoint, whatever).
"Busiest" and the activity log, precisely
- Busiest is a count of events (messages/joins/audit entries) any armed layer processed for that server, tracked in memory since the process started - it resets on restart and isn't a judgment about which server is causing trouble, just which one has the most traffic.
- The activity log is the last 30 events logged anywhere (any server,
any layer), kept in memory by
SmartLogger- seedocs/CACHE_ARCHITECTURE.md. The dashboard shows the most recent 10 of those.