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

Merge pull request #21 from mrteye/feat/auth-api-traefik-ingress-control-task-6742583984777370201
feat(tasks): create Traefik Universal Edge Ingress task file
2026-08-24 14:13:35 -07:00 · 2026-08-24 14:13:08 -07:00 · 2026-08-24 14:12:51 -07:00 · 2026-08-24 21:12:30 +00:00 · 2026-08-24 21:10:17 +00:00
3 changed files with 168 additions and 261 deletions
--- a/tasks/JULES_PROMPTS.md
+++ b/tasks/JULES_PROMPTS.md
@ -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`.
 ```
--- a/tasks/new/2026-0824.01.jul.feat.auth-api.traefik-ingress-control-2105.md
+++ b/tasks/new/2026-0824.01.jul.feat.auth-api.traefik-ingress-control-2105.md
@ -0,0 +1,53 @@
 # TASK METADATA
 - **Target Files:** `COMPOSE_CONVENTIONS.md`, `server/main.ts`, `server/auth-session.ts`, `server/db.ts`
 - **Core Objective:** Architect and formalize the Tier 1 Universal Global Edge Ingress Protection protocol for Traefik to enforce default-deny while supporting a dynamic, multi-tier bypass and guest sandbox matrix.
 - **Dependencies:** Database schema update for `apps` table (`is_public`, `bypass_paths`).
 - **Additional Important Notes:** Must align closely with `docs/FORWARDAUTH_REDIRECT_SPEC.md` for dual-response handling and rely entirely on Valkey L1/L2 caching to maintain sub-millisecond edge latency for dynamic routing decisions.
 ---
 ### 1. TASK METADATA
 (Defined in the header block above)
 ### 2. Architectural Considerations & Risks
 - **Risks:**
  - **Recursive Deadlocks (Self-Exemption):** Applying ForwardAuth globally introduces the risk of `auth-api` protecting itself, leading to an infinite authentication loop where users cannot reach the login page to authenticate. `auth-api` must be explicitly exempted.
  - **Health Probe Failures:** Traefik and orchestrator liveness/readiness probes (e.g., `/healthz`) might be blocked if they fall under the global ForwardAuth middleware, causing rolling restart failures.
  - **Latency Regressions:** If `auth-api` queries PostgreSQL on every request to evaluate dynamic bypass paths (`is_public`, `bypass_paths`, or CIDRs), performance will tank. We must guarantee this data is piggybacked onto the existing Valkey app caching flow.
 - **Alternatives & Architectural Decisions:**
  - **Dynamic Bypass Matrix:** Evaluated inside `auth-api` with Valkey L1/L2 caching instead of dynamic Traefik HTTP providers to avoid sync overhead and polling complexity.
  - **Universal Bypasses (Hybrid Approach):**
    - Critical infrastructural paths (`/.well-known/acme-challenge/*`, `/healthz`) bypass ForwardAuth directly at the Traefik router level to prevent lockout during restarts.
    - Semantic app paths (`/api/public/*`, `/webhooks/*`) and CIDR allowlists are evaluated within `auth-api` for centralized auditing and hot-reloading.
  - **Unregistered App Handling:** Adheres to the Dual-Response protocol. Web browsers receive a `302 Redirect` to a polished Hono SSR error page (`/errors/unregistered`), while API/cURL clients receive a fast `403 Forbidden` response.
  - **Guest Sandboxes:** Handled natively via a Valkey ephemeral session with an `account_status: "guest"` and `X-Forwarded-Scopes: guest,trial`. Seamless in-flight passkey promotion transitions them to full users.
 ### 3. Proposed Implementation
 1. **Global Default-Deny Configuration:**
   - Document how Traefik's `entryPoints.websecure.http.middlewares` should be updated to universally apply the `auth-forward@docker` middleware.
   - Define the explicit router priority and empty middleware override required for `auth-api` and ACME challenge routers to guarantee self-exemption.
   - Define the mechanism for explicit host-level application bypass where fully public applications (e.g. landing pages, sandboxes) can use specific Docker labels (like `traefik.http.routers.app.middlewares=`) to bypass ForwardAuth entirely at the edge without traversing to `auth-api`.
 2. **Schema & Database Updates:**
   - Add database migrations for the `apps` table:
     - `is_public` (boolean, default `false`)
     - `bypass_paths` (text array, default `[]`)
     - `allowed_cidrs` (text array, default `[]`)
 3. **Valkey Caching Upgrades (`server/auth-session.ts`):**
   - Update `getAppByHost` to SELECT and cache the new `is_public`, `bypass_paths`, and `allowed_cidrs` fields within the `auth:app_by_host:<host>` Valkey payload.
 4. **Dynamic Bypass & Dual-Response Execution (`server/main.ts`):**
   - In `GET /api/forward-auth`:
     - **Unregistered App Handling:** If `getAppByHost` returns null, evaluate the `Accept` header. Issue a `302 Redirect` to `https://auth.atyg.org/errors/unregistered?host=...` if it contains `text/html`, otherwise return `403 Forbidden`.
     - **Path & CIDR Exemption Check:** Before checking for a valid session, evaluate the requested URI (`X-Forwarded-Uri`) and Client IP against the cached `bypass_paths`, `allowed_cidrs`, and `is_public` flags.
     - **Immediate Allowance:** If the request matches a bypass rule or is public, immediately return `200 OK` without querying `getAuthenticatedUser()`.
 5. **Ephemeral Guest Session Generation:**
   - Expose a new endpoint (e.g., `/api/guests/sandbox`) that provisions a Valkey session ID without requiring PostgreSQL insertion.
   - Attach `account_status: "guest"` to the Valkey payload and map the corresponding `X-Forwarded-Scopes`.
   - Update the `/api/passkeys/register/verify` flow to detect `upgrade_session` and persist the guest's UUID and session context to the `users` table upon successful passkey verification.
--- a/tasks/new/2026-0824.01.jul.story.app-launchpad.sso-launchpad-and-logout-2100.md
+++ b/tasks/new/2026-0824.01.jul.story.app-launchpad.sso-launchpad-and-logout-2100.md
@ -0,0 +1,115 @@
 # TASK METADATA
 - **Target Files:** `ui/mod.ts`, `ui/components/AppLaunchpadPage.tsx`,
  `ui/components/AuthenticatedLayout.tsx`, `server/main.test.ts`,
  `docs/HYBRID_INGRESS_PLAYBOOK.md`
 - **Core Objective:** Architect and formalize the specification and
  implementation plan for Universal Logout Return-Path Preservation, Central SSO
  Application Launchpad, Hybrid Ingress Routing Playbook, and Strict Additive
  Security Audit.
 - **Dependencies:** Existing UI layout system,
  `docs/FORWARDAUTH_REDIRECT_SPEC.md`, `server/auth-session.ts`, Merkle Tree
  Audit Ledger.
 - **Additional Important Notes:** Must adhere strictly to Zero-Trust
  invisibility for ungranted apps. Must maintain 100% test coverage and ensure
  zero regressions across WebAuthn, SSS, and RFC 9421.
 ---
 ## 2. Architectural Considerations & Risks
 Before detailing implementation steps, the following risks and constraints must
 be strictly adhered to:
 - **Risks:**
  - **Open-Redirect Vulnerability (CWE-601):** The `/logout?redirect=` endpoint
    is a prime target for phishing if not strictly validated against an approved
    whitelist.
  - **RBAC Data Leakage:** Exposing ungranted applications, even visually
    disabled, leaks internal network topology and service architecture.
  - **Regression of Cryptographic Core:** Modifying session lifecycle hooks
    (like logout) must not break the Merkle Tree Audit Ledger, WebAuthn PRF
    flows, or Edge Signatures.
 - **Alternatives & Architecture Decisions:**
  - **Redirect Validation:** We will strictly implement the `isSafeRedirectUrl`
    logic defined in `docs/FORWARDAUTH_REDIRECT_SPEC.md` (`*.atyg.org`,
    `localhost`, relative paths) for both login and logout flows.
  - **Zero-Knowledge Launchpad:** Regular users will only see applications they
    have explicit grants for. Global Admins (`isGlobalAdmin = true`) will see
    all fleet applications.
  - **Cryptographic Auditing:** Explicit audit events (`logout_success`,
    `open_redirect_intercepted`) will be injected directly into the RFC 6962
    Merkle tree upon logout operations.
 ## 3. Proposed Implementation
 The implementation must be executed in the following strict phases:
 ### Phase 1: Logout Return-Path Preservation (`GET /logout`)
 1. **Update `ui/mod.ts`:**
   - Extract the `redirect` query parameter in the `GET /logout` handler.
   - Implement strict whitelist validation (`isSafeRedirectUrl`):
     - Must allow relative paths (`/`).
     - Must allow explicit wildcard `*.atyg.org` or `localhost`.
   - **Audit Integration:**
     - If validation fails, immediately log an `open_redirect_intercepted` event
       to the Merkle Audit Ledger (including client IP, original requested URL,
       and blocked destination), then discard the parameter.
     - Upon successful session destruction (cache + DB wipe), log a
       `logout_success` audit event.
   - Redirect the user to `/login?redirect=${encodeURIComponent(safeRedirect)}`
     (if a safe redirect exists), otherwise fallback to `/login`.
 ### Phase 2: Central SSO Application Launchpad (App Switcher)
 1. **Create `ui/components/AppLaunchpadPage.tsx`:**
   - Build a pure Hono SSR JSX component rendering interactive application
     cards.
   - Each card must display the app name, description, role indicator (e.g.,
     `Admin`, `Operator`), and a 1-click launch link.
 2. **Update Route `GET /dashboard` in `ui/mod.ts`:**
   - Change the default `/dashboard` redirect to render `AppLaunchpadPage`.
   - Update navigation in `ui/components/AuthenticatedLayout.tsx` to include the
     new Launchpad as the primary dashboard view.
 3. **Zero-Trust Query Logic:**
   - Fetch the authenticated user and their `isGlobalAdmin` status.
   - **Regular Users:** Query `grants` JOIN `apps` to fetch strictly only the
     applications they possess an active grant for.
   - **Global Admins:** Query `apps` to fetch all applications, annotating them
     with an `[Admin]` badge and providing a direct link to the IAM Management
     Console.
 ### Phase 3: Hybrid Ingress Routing Pattern & Playbook
 1. **Document `docs/HYBRID_INGRESS_PLAYBOOK.md`:**
   - Provide concrete reference configurations for consumer web applications
     requiring hybrid public splash views alongside protected private cockpits.
   - Detail the dual-routing pattern: Traefik edge ForwardAuth protection for
     `/control-panel`, `/ws`, `/api/*` + App/SDK-level SSR hydration on the root
     `/`.
 ### Phase 4: Strict Additive Security & Regression Audit
 1. **Test Coverage Additions (`server/main.test.ts`):**
   - Write tests validating the open-redirect whitelist logic in `/logout`.
   - Write tests verifying Zero-Knowledge visibility of the Launchpad (users see
     only granted apps, admins see all).
   - Write tests verifying the new audit log events (`logout_success`,
     `open_redirect_intercepted`) are correctly appended.
 2. **Pre/Post Hermetic Test Mandate:**
   - All 42+ existing unit tests in `server/*.test.ts` and `sdk/*.test.ts` MUST
     pass hermetically before and after modifications.
 3. **End-to-End QA Checklist (To be included in Completion Report):**
   - [ ] Verify WebAuthn PRF extension negotiation (`/api/login/challenge` &
         `/api/register/verify`).
   - [ ] Verify 2-of-3 SSS Wasm memory zeroization and key reconstruction
         (Scenario A & Scenario B).
   - [ ] Verify RFC 9421 Ed25519 signature verification against the O(1) Valkey
         fingerprint set.
 4. **Coverage Validation Requirement:**
   - Run the following command before final submission:
     `deno test -A --unstable-ffi --coverage=cov_profile && deno coverage cov_profile`
   - Include the generated coverage table in the PR description / final
     completion summary.
Author	SHA1	Message	Date
Tyler Gillispie	443df1c2ce	chore(tasks): remove JULES_PROMPTS.md to eliminate agent prompt confusion	2026-08-24 14:13:35 -07:00
Tyler Gillispie	226d04228b	Merge pull request #21 from mrteye/feat/auth-api-traefik-ingress-control-task-6742583984777370201 feat(tasks): create Traefik Universal Edge Ingress task file	2026-08-24 14:13:08 -07:00
Tyler Gillispie	9ace888b4b	Merge pull request #20 from mrteye/feat/sso-launchpad-task-file-4077230937799430847 docs: draft phase 4 sso launchpad and logout spec	2026-08-24 14:12:51 -07:00
google-labs-jules[bot]	5f31989137	feat(tasks): create Traefik Universal Edge Ingress task file Generates `tasks/new/2026-0824.01.jul.feat.auth-api.traefik-ingress-control-2105.md` outlining the architecture and implementation steps for: - Traefik global default-deny ForwardAuth setup - Valkey-cached dynamic database bypass matrix (`is_public`, `bypass_paths`) - Hybrid universal path and CIDR exemptions - Dual-response error handling (302 vs 403) for unregistered apps - Ephemeral guest sandbox flow with passkey promotion Co-authored-by: mrteye <1945243+mrteye@users.noreply.github.com>	2026-08-24 21:12:30 +00:00
google-labs-jules[bot]	b0dd2d098c	docs: draft phase 4 sso launchpad and logout spec Drafted the task markdown file for Phase 4 covering Central SSO Application Launchpad, Logout Return-Path Preservation, Hybrid Ingress Gateway Protocol, and Strict Additive Security Audit. Co-authored-by: mrteye <1945243+mrteye@users.noreply.github.com>	2026-08-24 21:10:17 +00:00