11 KiB
11 KiB
Orchestrator Task Prompts for Jules (System Analyst & Implementation)
This document contains pre-configured orchestrator prompts strictly following
tasks/META_PROMPT.md
and
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.2 | Ghost Cockpit Protocol & WebSocket Freeze/Re-Auth | ✅ COMPLETE | docs/GHOST_COCKPIT_SPEC.md, sdk/hono.ts |
| Prompt 2.1 | RFC 9421 HTTP Signatures & Signature-Key (hwk) |
✅ COMPLETE | server/http_signatures.ts, server/main.ts |
| Prompt 3.1 | WebAuthn PRF Extension & Progressive Fallback | ✅ COMPLETE | server/main.ts, ui/public/auth-client.js |
| Prompt 3.3 | 2-of-3 SSS Recovery Matrix (Wasm/Rust) | ✅ COMPLETE | ui/components/RecoveryPage.tsx, wasm/ |
| Prompt 3.4 | RFC 6962 Merkle Tree Audit Ledger & STH | ✅ COMPLETE | server/audit_merkle.ts, server/audit.ts |
Phase 1 Prompts
Prompt 1.1: Ingress Grant Vector Injection (/api/forward-auth) — [STATUS: ✅ COMPLETE]
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) — [STATUS: ✅ COMPLETE]
Completed task:
tasks/complete/2026-0824.02.jul.feat.sdk.realtime-invalidation-bus-1200.md
Phase 2 Prompts
Prompt 2.2: The Ghost Cockpit Protocol Specification & Re-Auth Choreography — [STATUS: ✅ COMPLETE]
Completed task:
tasks/complete/2026-0824.01.jul.feat.sdk-hono.ghost-cockpit-protocol-0431.md
Prompt 2.1: RFC 9421 HTTP Message Signatures & Autonomous Signature-Key — [STATUS: ✅ COMPLETE]
Completed task:
tasks/complete/2026-0824.02.jul.feat.http-sigs.rfc9421-verification-0436.md
**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
**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
**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 — [STATUS: ✅ COMPLETE]
Completed task:
tasks/complete/2026-0824.01.jul.feat.spire-ffi.native-argon2-0352.md
Prompt 3.3: 2-of-3 Shamir's Secret Sharing (SSS) Wasm Recovery Matrix
**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 constant-time 2-of-3 Shamir's Secret Sharing (SSS) key splitting and reconstruction in WebAssembly/Rust for the client-side zero-downgrade recovery portal, with mandatory in-place memory zeroization (`Uint8Array.fill(0)`).
**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
* Implement constant-time polynomial interpolation over GF(256) in Rust and compile to a standalone Wasm module.
* In `ui/views/recovery.tsx`, execute the 2-of-3 share reconstruction inside an isolated sandbox iframe.
* Immediately after importing the reconstructed master key into WebCrypto as an unexportable `CryptoKey`, execute `.fill(0)` across all typed arrays to purge key material from heap memory.
**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.4: RFC 6962 Merkle Tree Audit Ledger with Micro-Batched STH
**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 an append-only RFC 6962 Merkle Tree audit ledger in PostgreSQL with 30–60 second micro-batching, Signed Tree Head (STH) computation signed by SPIRE server keys, and distributed witness broadcast over Valkey pub/sub.
**Suggestions & Initial Thoughts:**
*Here is our starting hypothesis. Treat these as ideas to evaluate, not rigid requirements:*
* Create `server/audit_merkle.ts` implementing Merkle tree leaf computation and inclusion proof generator (`verifyInclusionProof`).
* Implement a background micro-batcher sealing the tree head every 60 seconds (or 1,000 writes) without blocking relational write throughput.
* Broadcast the signed STH over Valkey pub/sub (`auth:audit:sth`) to independent witness nodes.
**Your Task:**
1. Research the codebase and analyze this objective against our current architecture in `server/audit.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`.