> ## Documentation Index
> Fetch the complete documentation index at: https://stars-components.js.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Why Stars Components

> The reasoning behind an HTTP-first Discord framework and a set of small, independent packages.

## The Need for HTTP-First Discord Bots

A Discord application does not need a gateway connection to answer slash commands. Discord can `POST` every
interaction to an HTTPS endpoint, and the application only has to verify the signature and reply.

That model fits how most bots are actually deployed today: stateless processes, horizontal scaling, serverless-style
platforms, zero-downtime rollouts. A gateway client, by contrast, holds a long-lived socket, needs shard coordination,
and must be resident even when nothing is happening.

[`@wolfstar/http-framework`](/packages/http-framework) owns exactly that surface: the HTTP server, Discord request
verification, interaction routing, piece stores, and the application-command registry.

## Small Packages Over One Framework

Stars Components is a monorepo of focused packages rather than a single dependency. Infrastructure helpers work in any
Node.js application; the framework packages form an optional stack on top of them.

```text theme={"system"}
Application
├─ @wolfstar/shared-http-pieces
├─ @wolfstar/shared-influx-pieces
└─ your commands and listeners
          │
Framework │
├─ @wolfstar/http-framework
├─ @wolfstar/plugin-i18next
├─ @wolfstar/i18next-backend
└─ @wolfstar/http-framework-test-utils
          │
Utilities │
├─ @wolfstar/env-utilities
├─ @wolfstar/influx-utilities
├─ @wolfstar/logger
├─ @wolfstar/safe-fetch
└─ @wolfstar/start-banner
          │
Services  │
├─ @wolfstar/reddit-helpers
├─ @wolfstar/twitch-helpers
└─ @wolfstar/weather-helpers
```

Adopting [`@wolfstar/safe-fetch`](/packages/safe-fetch) or [`@wolfstar/logger`](/packages/logger) in an existing
service costs one dependency and no framework buy-in. See [Architecture](/guide/architecture) for how the layers relate.

The split goes further than one repository. Optional `@wolfstar/http-framework` extensions — a REST API server, i18n,
modular subcommands — live in their own [`wolfstar-project/plugins`](https://github.com/wolfstar-project/plugins)
repository and release independently of the core framework, so picking one up never bumps
`@wolfstar/http-framework` itself. See the [Plugins](/guide/plugins) guide.

## Types as the Contract

Every package exposes its supported API through `src/index.ts` and explicit `package.json` export maps, so private
implementation files never become accidental public contracts. The [API reference](/api/index) is generated from those entry
points on every documentation build — it cannot drift from the code.

The same idea runs through the packages themselves: typed environment keys in
[`@wolfstar/env-utilities`](/packages/env-utilities), typed translation keys in
[`@wolfstar/plugin-i18next`](/packages/plugin-i18next), `Result` values instead of thrown errors in
[`@wolfstar/safe-fetch`](/packages/safe-fetch).

## Testable by Construction

Commands and listeners are plain classes discovered by a store, so they can be reloaded and tested independently.
[`@wolfstar/http-framework-test-utils`](/packages/http-framework-test-utils) dispatches interaction fixtures without
starting a network server — see [Testing Interactions](/guide/testing).

## Next Steps

* [Features](/guide/features) — what ships in the box
* [Getting Started](/quickstart) — create a bot in one command