> ## Documentation Index
> Fetch the complete documentation index at: https://docs.edgespark.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# The EdgeSpark harness model

> How EdgeSpark enforces security, correctness, and safety at the platform level — guardrails that make AI-generated code safe by default.

EdgeSpark is a **harness** — a platform that enforces correctness at runtime so that AI-generated code is safe by default. The harness catches entire categories of mistakes before they can reach production, without requiring agents or developers to write defensive logic themselves.

This is different from a framework like Hono or Next.js, which provide structure. A harness provides **constraints**: things the platform simply will not allow, regardless of what the code says.

## What the harness enforces

### Authentication is enforced by URL

You cannot accidentally create an unauthenticated route. The path of the route determines its auth requirement:

```
/api/*          → platform rejects unauthenticated requests before your code runs
/api/public/*   → your code runs, user populated if logged in
/api/webhooks/* → no auth check
```

An agent that writes a route at `/api/users` and forgets to add an auth check is still safe — the platform enforces it. The agent cannot opt out.

During `edgespark deploy`, the route analyzer categorizes every route by its auth convention and shows the summary before deploying:

```
Protected (login required, auth.user guaranteed):   3 routes
  GET    /api/users
  POST   /api/posts
  DELETE /api/posts/:id

Public (login optional, auth.user if logged in):   2 routes
  GET    /api/public/feed
  POST   /api/public/search

Webhooks (no auth check):                          1 routes
  POST   /api/webhooks/stripe
```

Any route **not** under `/api/*` causes the deploy to fail. There is no way to deploy code with an unsecured route outside the expected convention.

### Database writes are validated

Every SQL statement passes through the platform before it reaches the database. The following are blocked at runtime, regardless of what the code contains:

**Blocked — destructive:**

| Statement                     | Why blocked                     |
| ----------------------------- | ------------------------------- |
| `DELETE FROM` without `WHERE` | Irreversible data loss          |
| `DROP TABLE`                  | Destroys the table and all data |
| `DROP VIEW`, `DROP TRIGGER`   | Breaks dependent functionality  |
| `ALTER TABLE ... RENAME TO`   | Breaks existing references      |
| `ALTER TABLE ... DROP COLUMN` | Destroys column data            |

**Blocked — unsupported by D1:**

| Statement                     | Reason                           |
| ----------------------------- | -------------------------------- |
| `BEGIN`, `COMMIT`, `ROLLBACK` | D1 does not support transactions |
| `ATTACH`, `DETACH`            | Not supported                    |
| `PRAGMA`, `VACUUM`, `ANALYZE` | Not supported at runtime         |

Schema changes are declarative and repo-owned. You define app tables in `server/src/defs/db_schema.ts`, generate migrations with `edgespark db generate`, and apply them with `edgespark db migrate`. Runtime application code cannot execute DDL directly as part of normal request handling.

### Type safety at compile time

Generated files in `server/src/__generated__/` reflect platform-managed schema and runtime types. When an agent writes a query against a column that no longer exists, the TypeScript compiler catches it before deploy:

```
error TS2339: Property 'bio' does not exist on type 'typeof tables.users'
```

`edgespark deploy` runs `tsc --noEmit` and fails if there are type errors. You cannot deploy type-incorrect code.

### Bundle validation

The deploy pipeline validates the output bundle before uploading:

* Bundle must be ≤ 25 MB
* Must default-export the Hono app from `server/src/index.ts` (`export default app;`)
* Must export `drizzleSchema` and `buckets` from the defs barrel
* All routes must be under `/api/*`

Missing any of these fails the deploy with a descriptive error.

### Environment model

New public projects currently expose one default production environment. Public staging isolation is coming soon, but it is not part of the current documented workflow.

## The agent's role

The harness handles safety. The agent's role is to **build the feature** — write the route, define the query, handle the business logic. The platform handles the rest.

When an agent generates code that would violate a constraint, the deploy fails with a clear error. The agent reads the error, fixes the code, and deploys again. This tight loop is intentional: fail fast, fix precisely, ship confidently.

See [the deploy and test loop](/agents/deploy-and-test) for how this works in practice.

## See also

<Columns cols={2}>
  <Card title="Path-based auth" icon="lock" href="/concepts/path-based-auth">
    How URL conventions replace auth middleware and enforce login requirements.
  </Card>

  <Card title="Declarative workflow" icon="database" href="/agents/declarative-workflow">
    How to pull schema, write code against generated types, and deploy iteratively.
  </Card>

  <Card title="Deploy and test loop" icon="rotate" href="/agents/deploy-and-test">
    The current deploy workflow for agents while staging is still coming soon.
  </Card>

  <Card title="Handling errors autonomously" icon="triangle-exclamation" href="/agents/handling-errors">
    How to read and fix every category of deploy and runtime error.
  </Card>
</Columns>