auth-yes/tasks/complete/2026-0821.01.jul.story.auth-yes.extract-standalone-repo-1828.md

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).