tylerg/auth-yes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(tasks): remove JULES_PROMPTS.md to eliminate agent prompt confusion

Browse Source
This commit is contained in:
Tyler Gillispie 2026-08-24 14:13:35 -07:00
parent 226d04228b
commit 443df1c2ce
1 changed files with 0 additions and 261 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

261
tasks/JULES_PROMPTS.md
View File

@ -1,261 +0,0 @@
# Orchestrator Task Prompts for Jules (System Analyst & Implementation)
This document contains pre-configured orchestrator prompts strictly following
[`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).
---
## 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` |
| **Prompt 4.1** | Traefik Tier 1 Universal Global Ingress Control | ⏳ **IN PLANNING (Jules #6742583984777370201)** | `infra/`, Host Traefik Config |
| **Prompt 4.2** | SSO Launchpad, Logout Return-Path & Hybrid Ingress | ⏳ **IN PLANNING (Next Milestone)** | `ui/`, `server/`, `docs/` |
---
## 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`_
```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 — [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
```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 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
```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 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`.
```
---
## Phase 4 Prompts
### Prompt 4.1: Traefik Tier 1 Universal Global Ingress Control & Multi-Tier Bypass/Allowlist Matrix
```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:** Architect and formalize the Tier 1 Universal Global Edge Ingress Protection protocol for the central Traefik proxy. This system must enforce universal zero-trust ForwardAuth default-deny across all *.atyg.org domains while providing a comprehensive, user-friendly, and bulletproof multi-tier allowlist/bypass matrix for public applications, standard sub-paths, webhooks, and guest sandboxes.
**Core Scope & Architectural Requirements to Explore:**
1. **Universal Edge Perimeter Default-Deny:**
* Configure Traefik's `entryPoints.websecure.http.middlewares` to apply ForwardAuth (`auth-forward@docker` / `authyes-forwardauth`) globally.
* Any new container or service spun up on the network is secure by default on first boot without requiring manual per-service Docker label configuration.
2. **Self-Exemption & Infinite Loop Prevention:**
* `auth-api` (`auth.atyg.org`) must be explicitly exempt from the global entrypoint middleware chain to eliminate recursive self-interception deadlocks.
* Document the exact Traefik static/dynamic provider configuration or router priority overrides to guarantee clean self-exemption.
3. **Multi-Tier Bypass & Allowlist Matrix:**
* **A. Host-Level Application Bypass (Opt-Out Labels):**
- Allow public apps (e.g. `public.atyg.org`, landing pages, open trial sandboxes) to opt out of ForwardAuth via explicit Docker labels (e.g., overriding router middlewares to empty string or attaching a bypass middleware).
* **B. Universal Path-Level Exemptions (Prefix & Regex Rules):**
- Common public paths must always bypass authentication across ALL applications without per-app custom rules:
- `/.well-known/*` (WebAuthn, ACME/Let's Encrypt challenge, RFC 7638 JWK thumbprints, OIDC metadata).
- `/health`, `/healthz`, `/livez`, `/readyz` (Traefik, Portainer, and orchestrator liveness probes).
- `/api/public/*`, `/public/*` (Public assets, favicons, open fonts).
- `/webhooks/*` (GitHub, Gitea, Stripe incoming webhooks authenticated via HMAC signature rather than session cookies).
- `raw/branch/main/sdk/*` (Unauthenticated SDK consumption by external agents and microservices).
* **C. Database-Driven Dynamic Bypass Matrix (Management Console Controlled):**
- In Auth-Yes database schema (`apps` table), support dynamic `is_public` booleans and `bypass_paths: text[]` array so administrators can add or remove public paths via the Auth-Yes UI/REST API without restarting Traefik or editing Docker compose labels.
* **D. Network / CIDR Allowlists (Trusted Private Mesh):**
- Support CIDR-based bypasses (e.g. local Docker networks, WireGuard/Tailscale VPN subnets, or specific management IPs).
* **E. Ephemeral Guest Sandboxes (Use Case 11 Alignment):**
- Support open trial / guest exploration with temporary tokens and in-flight passkey promotion.
4. **User-Friendly Error Handling & UX (No Cryptic Errors):**
* **Unregistered App Handling:** If an unregistered domain hits Traefik ForwardAuth, render a polished Hono SSR "Application Unregistered" page with guidance rather than a raw plaintext 403 error.
* **Dual-Response Protocol Compliance:** Ensure all interactive browser flows receive HTTP 302 Redirect with full deep-link preservation (`?redirect=...`), while API/cURL calls receive clean HTTP 401 Unauthorized without HTML redirect loops.
**Your Task:**
1. Research the Traefik infrastructure conventions in `COMPOSE_CONVENTIONS.md`, `ONBOARDING.md`, `docs/FORWARDAUTH_REDIRECT_SPEC.md`, and `server/main.ts`.
2. Map out the `Target Files`, host configuration requirements, database migrations, and potential architectural risks.
3. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```
---
### Prompt 4.2: Central SSO Application Launchpad, Logout Return-Path Preservation & Hybrid Ingress Gateway Protocol
```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:** Architect and formalize the specification and implementation plan for:
1. Universal Logout Return-Path Preservation (`GET /logout?redirect=...`).
2. Central SSO Application Launchpad (App Switcher) on `auth.atyg.org/dashboard` and post-login fallback.
3. Hybrid Ingress Routing Pattern & Developer Playbook for consumer applications (e.g. public landing vs private cockpit).
4. Comprehensive Additive Security & Regression Audit across all previously implemented subsystems.
**Core Scope & Architectural Requirements to Explore:**
1. **Logout Return-Path Preservation (`GET /logout`):**
* Update `ui/mod.ts` `/logout` handler so that when consumers trigger single-sign-out via `GET /logout?redirect=...`, the return URL is parsed and validated against the open-redirect whitelist (`*.atyg.org`, `localhost`, and relative paths).
* After successfully wiping Valkey session cache and revoking wildcard `.atyg.org` / host cookies, redirect the browser to `/login?redirect=${encodeURIComponent(safeRedirect)}` (or direct return) to keep consumer navigation intact without breaking UX.
2. **Central SSO Application Launchpad (App Switcher):**
* When users log in directly on `auth.atyg.org/login` without a `?redirect=` parameter (or navigate to `/dashboard`), the default landing page must act as an intuitive SSO Launchpad.
* Query PostgreSQL `apps` and `grants` for the authenticated `userId` and render interactive application cards (e.g. ED-Droid Hub, Grafana Telemetry, Portainer Admin, IAM Console) with 1-click launch links and role indicators (`Admin`, `Operator`, `Viewer`).
* For Global Admins (`isGlobalAdmin = true`), display all fleet applications and direct links to user/grant management.
3. **Hybrid Ingress Routing Pattern & Playbook:**
* Document and provide concrete reference configurations for consumer web applications that require hybrid public splash views alongside protected private cockpits.
* Clarify the dual-routing pattern: Traefik edge ForwardAuth protection for `/control-panel`, `/ws`, `/api/*` + App/SDK-level SSR hydration on root `/`.
4. **Strict Additive Security & Regression Audit:**
* Ensure that adding dynamic launchpad tiles and logout redirect preservation introduces zero regressions or vulnerabilities:
- Open-Redirect Prevention (CWE-601): Absolute strict whitelist validation.
- Zero-Trust Default-Deny RBAC: Verify `isGlobalAdmin` and `getUserGrant` continue to strictly govern application tile visibility and ingress grant injection.
- RFC 9421 Edge Signatures, WebAuthn PRF (3.1), 2-of-3 SSS Recovery (3.3), and RFC 6962 Merkle Tree Audit Ledger (3.4) must remain 100% untouched and operational.
- Maintain 100% test coverage across all existing and new unit tests.
**Your Task:**
1. Research the existing UI components in `ui/`, database schemas in `server/db.ts`, session handling in `server/auth-session.ts`, and redirect specs in `docs/FORWARDAUTH_REDIRECT_SPEC.md`.
2. Map out the `Target Files`, required UI component updates (`AppLaunchpadPage.tsx` / `SessionsPage.tsx`), route handlers in `ui/mod.ts`, and test cases in `server/main.test.ts`.
3. Draft the task file in `tasks/new/` strictly adhering to the naming conventions, header metadata, and mandatory structure defined in `tasks/GUIDELINES.md`.
```