85 lines
3.8 KiB
Markdown
85 lines
3.8 KiB
Markdown
# 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`).
|