# TASK METADATA

- **Target Files:**
  - `auth-yes/*`
  - `spire_ffi/*`
  - `infra/setup.ts`
  - `deno.json`
- **Core Objective:** Extract `auth-yes`, `spire_ffi`, and its related infra
  scripts and configurations into a pristine, standalone directory representing
  a new isolated workspace repository.
- **Dependencies:** None.
- **Additional Important Notes:** The extracted code must represent a modular
  Deno workspace containing `sdk/`, `server/`, `ui/`, and `spire_ffi/`. All
  auth-related infra setup must be excised from the parent repository
  (`ed-droid`), and the `auth-yes` databases (Postgres, Valkey) must be 100%
  isolated. The SDK should be ready for potential JSR/Git distribution.

---

## Architectural Considerations & Risks

- **Risks:**
  - **Shared Dependencies:** Breaking internal imports inside the `ed-droid`
    mono-repo that rely on `auth-yes` internals. The `ed-droid` core must pivot
    to relying purely on HTTP/ForwardAuth and the `@auth-yes/sdk`.
  - **FFI Rust Compilation:** Moving `spire_ffi` could break relative path cargo
    configurations, `.gitignore` behaviors, or Docker multi-stage build contexts
    in the new repository.
  - **Infrastructure Script Bloat:** Moving setup logic from `infra/setup.ts`
    into the standalone repo requires untangling Deno CLI commands, file
    generation logic (e.g., `compose.auth.yml`), and configuration parsing
    currently tightly bound to `ed-droid`'s main setup process.

- **Alternatives:**
  - **Alternative Extraction Tooling:** Instead of manually copying and
    rewriting imports, we could use Git history rewriting tools (like
    `git filter-repo`) to extract `auth-yes` while preserving git history.
    However, given the requirement to synthesize a clean staging directory ready
    for `git init`, a structured scripted extraction and clean workspace
    definition is the preferred, native, and cleaner approach here.

## Proposed Implementation

### Phase 1: Establish the Staging Skeleton

1. Create an extraction staging directory (e.g., `.extract_auth_yes/`).
2. Initialize a modular `deno.json` at the root of the staging directory
   defining workspaces: `sdk`, `server`, and `ui`.
3. Scaffold the target directories: `sdk/`, `server/`, `ui/`, `spire_ffi/`, and
   `infra/`.

### Phase 2: Code & Configuration Extraction

1. **SDK, Server, & UI:** Migrate the contents of `auth-yes/sdk`,
   `auth-yes/server`, and `auth-yes/ui` into their respective workspace
   directories in the staging area. Update internal relative imports.
2. **SDK Export:** Ensure `sdk/deno.json` exports `mod.ts` cleanly so it can be
   consumed independently (no JSR publishing required immediately).
3. **Rust FFI:** Move `spire_ffi/` completely into the staging area. Verify
   `Cargo.toml` and `build.rs` paths remain valid.

### Phase 3: Infrastructure Extraction

1. Extract `auth-yes` and Spire specific setup logic from
   `ed-droid/infra/setup.ts` and author a dedicated setup tool in the standalone
   repository (e.g., `infra/setup.ts`).
2. The standalone repo's setup tool must independently handle
   `compose.auth.yml`, `compose.spire.yml`, and environment templates.
3. Completely remove auth and spire logic from the parent
   `ed-droid/infra/setup.ts`.

### Phase 4: CI/CD & Docker Boundaries

1. Copy and adjust the multi-stage `Dockerfile` into the standalone root,
   ensuring the build context supports Deno workspaces (e.g., copying the root
   `deno.json` and selectively copying workspace members).
2. Validate that `auth-yes` explicitly mandates its own PostgreSQL and Valkey
   data stores, ensuring absolute zero direct database coupling with `ed-droid`.

### Phase 5: Final Review & Preparation

1. Run `deno fmt`, `deno lint`, and `deno check` against the staged workspace.
2. Ensure the `.extract_auth_yes/` directory is pristine, isolated, and ready to
   be initialized as a fresh remote Git repository (`git init`).