docs(tasks): update execution roadmap and completed statuses in JULES_PROMPTS.md

This commit is contained in:
Tyler Gillispie 2026-08-23 21:28:15 -07:00
parent 5db9108ecd
commit 731fa825f1

View File

@ -1,65 +1,43 @@
# 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.
and [`tasks/GUIDELINES.md`](file:///home/tylerg/p/data/auth-yes/tasks/GUIDELINES.md).
---
## Progress & Execution Roadmap
| Prompt ID | Task Scope | Status | Target File |
| :--- | :--- | :--- | :--- |
| **Prompt 1.1** | Ingress Grant Vector Injection (`/api/forward-auth`) | ✅ **COMPLETE** | `server/main.ts`, `server/auth-session.ts` |
| **Prompt 1.2** | SDK Real-Time Invalidation Event Bus (`@auth-yes/sdk`) | ✅ **COMPLETE** | `sdk/mod.ts` |
| **Prompt 3.2** | Native SIMD Argon2id Derivation in `spire_ffi` | ✅ **COMPLETE** | `spire_ffi/src/lib.rs`, `server/spire_ffi.ts` |
| **Prompt 2.1** | RFC 9421 HTTP Signatures & `Signature-Key` (`hwk`) | ⏳ **READY TO RUN** | `server/http_signatures.ts`, `sdk/` |
| **Prompt 2.2** | Ghost Cockpit Protocol & WebSocket Freeze/Re-Auth | ⏳ **READY TO RUN** | `docs/GHOST_COCKPIT_SPEC.md`, `sdk/hono.ts` |
| **Prompt 3.1** | WebAuthn PRF Extension & Progressive Fallback | ⏳ **PENDING (Phase 3)** | `server/main.ts`, `ui/views/` |
| **Prompt 3.3** | 2-of-3 SSS Recovery Matrix (Wasm/Rust) | ⏳ **PENDING (Phase 3)** | `ui/views/recovery.tsx` |
| **Prompt 3.4** | RFC 6962 Merkle Tree Audit Ledger & STH | ⏳ **PENDING (Phase 3)** | `server/audit_merkle.ts` |
---
## Phase 1 Prompts
### Prompt 1.1: Ingress Grant Vector Injection (`/api/forward-auth`)
### Prompt 1.1: Ingress Grant Vector Injection (`/api/forward-auth`) — [STATUS: ✅ COMPLETE]
```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`.
```
_Completed task: `tasks/complete/2026-0824.03.jul.feat.auth-api.ingress-grant-injection-1200.md`_
---
### Prompt 1.2: SDK Real-Time Invalidation Event Bus (`@auth-yes/sdk`)
### Prompt 1.2: SDK Real-Time Invalidation Event Bus (`@auth-yes/sdk`) — [STATUS: ✅ COMPLETE]
```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`.
```
_Completed task: `tasks/complete/2026-0824.02.jul.feat.sdk.realtime-invalidation-bus-1200.md`_
---
## Phase 2 Prompts
## Phase 2 Prompts (NEXT BATCH TO RUN)
### Prompt 2.1: RFC 9421 HTTP Message Signatures & Autonomous `Signature-Key`
### Prompt 2.1: RFC 9421 HTTP Message Signatures & Autonomous `Signature-Key` — [STATUS: ⏳ READY]
```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/.
@ -129,26 +107,9 @@ and subsequently execute them.
---
### Prompt 3.2: Native SIMD Argon2id Derivation in `spire_ffi` Rust Crate
### Prompt 3.2: Native SIMD Argon2id Derivation in `spire_ffi` Rust Crate — [STATUS: ✅ COMPLETE]
```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`.
```
_Completed task: `tasks/complete/2026-0824.01.jul.feat.spire-ffi.native-argon2-0352.md`_
---