# TASK METADATA

- **Target Files:** `auth-yes/deno.json`, `auth-yes/sdk/deno.json`,
  `auth-yes/server/deno.json`, `auth-yes/ui/deno.json`, `auth-yes/sdk/gen/*`
- **Core Objective:** Architect the modular Deno workspace structure for the
  standalone auth-yes repository to ensure `@auth-yes/sdk` is fully isolated and
  cleanly exportable.
- **Dependencies:** None.
- **Additional Important Notes:**
  - Package naming standard: `@auth-yes/sdk`, `@auth-yes/server`,
    `@auth-yes/ui`.
  - `@auth-yes/sdk` must have zero database or server imports and be consumable
    independently.
  - UI JSX compilation relies on `"jsx": "react-jsx"` with
    `"jsxImportSource": "jsr:@hono/hono@4/jsx"` (pure Hono SSR, zero React
    dependencies).

---

## Architectural Considerations & Risks

- **Risks:** The primary risk is a circular dependency or importing server-side
  logic into the SDK, which would break the isolation of the SDK. If the SDK
  depends on the server, external consumers (like ed-droid) will be forced to
  download unnecessary and potentially insecure backend dependencies.
- **Dependency Decoupling for Contracts:** The generated ConnectRPC contracts
  (`auth_pb.ts` and `auth_connect.ts`) currently reside in `server/gen/`. To
  ensure the SDK has 100% zero dependencies on `./server`, these generated files
  must be moved into the SDK (e.g., `sdk/gen/`). This way, consumers of
  `@auth-yes/sdk` will have all necessary type definitions and client stubs
  without needing any server files. The server package can then import these
  service contracts from the SDK.
- **JSX Compiler Standard (Zero React):** TypeScript and Deno use
  `"jsx": "react-jsx"` as the compiler standard for the modern JSX transform.
  When paired with `"jsxImportSource": "jsr:@hono/hono@4/jsx"`, TypeScript
  targets Hono's lightweight native SSR engine without pulling in any React
  runtime or dependencies.
- **Alternatives:** We could extract the proto contracts into a separate fourth
  workspace member (e.g., `api-contracts`). However, moving them directly into
  the SDK is simpler and provides exactly what external consumers need in a
  single package.

## Proposed Implementation

### Phase 1: Root Workspace Definition

1. Create a root `deno.json` in `auth-yes/` managing workspace members:
   `"./sdk"`, `"./server"`, `"./ui"`.
2. Configure workspace-wide tasks (`lint`, `fmt`, `check`, `test`).

### Phase 2: SDK Package Isolation

1. Create `auth-yes/sdk/deno.json` with package name `@auth-yes/sdk`, version
   `0.1.0`, and export definition (`"exports": "./mod.ts"`).
2. Move the generated ConnectRPC contracts from `server/gen/` into `sdk/gen/`.
3. Update `sdk/mod.ts` to export client functions and proto types, ensuring zero
   imports point to `../server` or `../ui`.

### Phase 3: Server and UI Package Configuration

1. Create `auth-yes/server/deno.json` with package name `@auth-yes/server`.
2. Update `auth-yes/server/main.ts` to import service contracts directly from
   `@auth-yes/sdk`.
3. Create `auth-yes/ui/deno.json` with package name `@auth-yes/ui`, including:
   ```json
   "compilerOptions": {
     "jsx": "react-jsx",
     "jsxImportSource": "jsr:@hono/hono@4/jsx"
   }
   ```
4. Verify that the Rust `spire_ffi` crate is properly referenced by `server/`
   and is not exposed or imported by `@auth-yes/sdk`.

### Phase 4: Workspace Verification & Quality Gates

1. Run `deno fmt` across all workspace members.
2. Run `deno lint` to ensure zero import violations.
3. Run `deno check sdk/**/*.ts server/**/*.ts ui/**/*.ts` to verify clean
   cross-package type resolutions.
4. Run `deno test -A` to verify test suite execution.