# Orchestrator Task Prompts for Jules (System Analyst & Implementation)

This document contains pre-configured orchestrator prompts strictly following
the
[`tasks/META_PROMPT.md`](file:///home/tylerg/p/data/auth-yes/tasks/META_PROMPT.md)
and
[`tasks/GUIDELINES.md`](file:///home/tylerg/p/data/auth-yes/tasks/GUIDELINES.md)
standards. Use these prompts to instruct Jules to plan each task in `tasks/new/`
and subsequently execute them.

---

## Phase 1 Prompts

### Prompt 1.1: Ingress Grant Vector Injection (`/api/forward-auth`)

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** Implement Ingress Grant Vector Injection in the `/api/forward-auth` endpoint so that Traefik ForwardAuth injects flattened user grant headers (`X-Forwarded-User-Id`, `X-Forwarded-User-Name`, `X-Forwarded-Scopes`, `X-Forwarded-App-Id`) into downstream application requests for Byte-1 SSR UI hydration.

**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   In `server/main.ts`, extract the `X-Forwarded-Host` header during `GET /api/forward-auth`.
*   Match the host against registered applications in PostgreSQL/Valkey to resolve `app_id`.
*   Evaluate the user's active RBAC grants in Valkey/PostgreSQL. If valid, return HTTP 200 with `X-Forwarded-User-Id`, `X-Forwarded-User-Name`, `X-Forwarded-Scopes: role1,role2`, and `X-Forwarded-App-Id`.
*   If the user has no grant for the target app, enforce Default-Deny by returning HTTP 403 Forbidden.

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture in `server/main.ts`, `server/db.ts`, and `server/valkey.ts`. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```

---

### Prompt 1.2: SDK Real-Time Invalidation Event Bus (`@auth-yes/sdk`)

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** Extend `@auth-yes/sdk` with a real-time event emitter listener for Valkey 8 RESP3 push invalidation events so downstream microservices (e.g. `ed-droid`) can terminate live WebSocket telemetry connections immediately upon session revocation.

**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   In `sdk/mod.ts`, integrate a lightweight EventEmitter or custom callback map (`authSdk.on("invalidate", (token) => ...)`).
*   In `initValkeyClient()`, when the `push` event receives an `"invalidate"` message from Valkey 8 BCAST tracking, iterate over the invalidated keys and trigger all registered callback handlers.
*   Ensure zero memory leaks by providing an `authSdk.off("invalidate", handler)` cleanup method.

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture in `sdk/mod.ts` and `sdk/mod.test.ts`. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```

---

## Phase 2 Prompts

### Prompt 2.1: RFC 9421 HTTP Message Signatures & Autonomous `Signature-Key`

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** Implement RFC 9421 HTTP Message Signatures verification for edge nodes and headless daemons, utilizing `Signature-Input` and `Signature-Key` with Header Web Key (`hwk`) in Octet Key Pair (`OKP`) format, validated against an $O(1)$ Valkey authorized fingerprint set in under 5 microseconds.

**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   Create a pure Deno WebCrypto/Ed25519 validator module in `server/http_signatures.ts`.
*   Parse RFC 9421 canonical components (`@method`, `@authority`, `@path`, `content-digest`, `created`, `expires`, `nonce`).
*   Extract the inline Ed25519 public key from `Signature-Key: hwk="..."` and verify the SHA-256 fingerprint exists in Valkey's authorized set (`auth:hwk:fingerprints`).
*   Verify the Ed25519 digital signature over the canonical signature base with strict $\pm 30$s timestamp drift tolerance.

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture in `server/` and `sdk/`. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```

---

### Prompt 2.2: The Ghost Cockpit Protocol Specification & Re-Auth Choreography

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** Formalize the Ghost Cockpit Protocol specification and write server/client reference helpers in `@auth-yes/sdk/hono` to support non-destructive WebSocket telemetry freezes and seamless in-flight WebAuthn re-authentication.

**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   Document the protocol choreography in `docs/GHOST_COCKPIT_SPEC.md`.
*   Create a reusable WebSocket session guard helper in `sdk/hono.ts` that listens to `authSdk.on("invalidate")` and emits the `{ "type": "AUTH_REVOKED", "reason": "SESSION_EXPIRED" }` control frame before closing the socket.
*   Provide a client-side TypeScript snippet demonstrating state-freeze in memory and zero-redirect background WebAuthn re-authentication.

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture in `sdk/hono.ts` and `docs/`. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```

---

## Phase 3 Prompts

### Prompt 3.1: WebAuthn PRF Extension & Progressive Fallback

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** Implement WebAuthn PRF (Pseudo-Random Function) extension support in Auth-Yes registration and login flows, including progressive feature detection (`getClientExtensionResults()?.prf?.enabled`) and dual-salt evaluation (`eval.first`, `eval.second`) for atomic envelope re-encryption.

**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   In `server/main.ts` (SimpleWebAuthn challenge generation), request the `prf: {}` extension during passkey registration.
*   In `ui/views/register.tsx` and `ui/views/login.tsx`, evaluate the PRF salt during `navigator.credentials.get()`.
*   If PRF is supported by the authenticator, derive the 256-bit AES-GCM Key Encryption Key (KEK) using HKDF over the 32-byte PRF output.
*   If `getClientExtensionResults()?.prf?.enabled` is false, gracefully continue standard signature-only authentication without blocking login.

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture in `server/` and `ui/`. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```

---

### Prompt 3.2: Native SIMD Argon2id Derivation in `spire_ffi` Rust Crate

```text
**Role:** Act as a System Analyst and Solutions Architect. Do not execute code or modify the codebase during this session. Your sole deliverable is to generate a task file in tasks/new/.

**The Objective:** Implement high-throughput native Argon2id derivation (12 iterations, 64 MiB memory, 128-bit salt, 256-bit output key) in the `spire_ffi` Rust crate to accelerate server-side Hot Share encryption and zero-knowledge voucher hashing.

**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
*   Add the `argon2` Rust crate with SIMD acceleration (`argon2 = { version = "0.5", features = ["std"] }`) to `spire_ffi/Cargo.toml`.
*   Export a C-compatible FFI function `argon2id_derive(password, salt, iterations, memory_kb, out_buf)`.
*   Expose `deriveArgon2idKey()` in `server/spire_ffi.ts` using Deno FFI (`Deno.dlopen`).
*   Include comprehensive unit tests and fallback behavior in `server/spire_ffi.test.ts`.

**Your Task:** 
1. Research the codebase and analyze this objective against our current architecture in `spire_ffi/` and `server/spire_ffi.ts`. 
2. Critically evaluate our suggestions: Do they make technical sense, or is there a cleaner, more native, or more modular approach?
3. Map out the `Target Files`, prerequisites/dependencies, and explicitly identify potential architectural risks, regressions, or friction.
4. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```