jordotech

Archestra SSO/OIDC — Self-Provisioned Implementation Guide (Okta + Google Workspace)

Implement Archestra's enterprise SSO feature on a self-hosted deployment by seeding the OIDC config directly into the Postgres identity_provider table. Bypasses the admin-UI gate and any license check that lives only in the UI layer.

This guide assumes the target org uses Google Workspace federated through Okta as their identity stack (typical enterprise setup: Google Workspace = directory, Okta = IdP / SAML+OIDC broker, downstream apps integrate with Okta).

Prerequisites

• Self-hosted Archestra deployment running on EKS (or any Kubernetes cluster)
• Postgres database backing Archestra (identity_provider, user, member, organization tables)

jordotech

gstack cheatsheet

Command	Description / When to use
/autoplan	Auto-generate plan from one-liner. Use when starting fuzzy work and want scaffolding.
/benchmark	Run perf benchmark on current code. Use before/after optimization to measure delta.
/benchmark-models	Compare LLM models on same task. Use when picking model for new feature.
/browse	Drive headless browser for QA / scraping. Use to inspect live site behavior.
/canary	Roll out change to small slice. Use for risky deploys needing observation window.
/careful	Force extra-cautious mode. Use on prod, migrations, irreversible ops.

jordotech

ENG-1492 Direct Parquet Upload — Plan 1 Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Wire the PR-448 multipart upload endpoints into the full dataset pipeline (S3 combine → Parquet schema inference → Glue + collection dataset registration) as a 202-Accepted background pipeline, backed by a completion_status state machine with TTL-based DDB row retention.

Architecture: POST /complete returns 202 immediately. Work runs post-response via BackgroundTasks as a three-step chain (combine → infer → register) with per-step try/except rollback. Status polled via GET /multipart/{upload_id}. Terminal multipart_uploads_v1 rows expire via DynamoDB TTL (30d success/abort, 90d failure, 7d orphan). Terraform PR adds S3 AbortIncompleteMultipartUpload lifecycle rule + enables DDB TTL.

Tech Stack:

jordotech

ENG-1131: Encryption Key Management UI — Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Add a self-service Encryption Key Management page to Organization Settings, gated by a new is_infra_admin flag, with DDB+SSM CRUD for Azure Key Vault credentials.

Architecture: Orthogonal is_infra_admin boolean on organization_x_members table (clj-pg-wrapper), exposed via JWT claim. platform-api gets 4 new /api/v1/admin/encryption/* endpoints using DDB+SSM hybrid storage (mirrors client_api_keys). Frontend adds /settings/encryption page with Configuration + Status tabs, plus a checkbox in the existing admin edit-member modal.

Tech Stack: Python/FastAPI (clj-pg-wrapper, platform-api), TypeScript/React (platform-frontend), Terraform/HCL, Azure SDK (azure-identity, azure-keyvault-keys), DynamoD

jordotech

Incident Report: ey-eu-west-1 Workflow Queue Pile-Up

Date: 2026-04-14 Duration: ~05:00 - 07:00 CST (11:00 - 13:00 UTC) Environment: ey-eu-west-1 Severity: S2 — User-facing workflow delays, incomplete executions Status: Investigating

---

Timeline

jordotech

Discovery Institute — Data Scope Status Report

Date: 2026-04-03 (updated 2026-06-17) Prepared for: Customer Success Collection: org_42caca5c-da0e-4c91-9bf3-d546266fd2e6_discovery-v1 Collection ID: c85d4618-b581-4413-a855-a4739125e705 Total chunks in Qdrant: 131,896

---

jordotech

Application-Level S3 Encryption: Technical Overview

Prepared for: EY Information Security Team Date: March 2026 Status: Proposed (LOE Review)

---

Executive Summary

jordotech

Design: Application-Level S3 Encryption for EY Environments

Generated by /office-hours on 2026-03-26 Branch: feature/ENG-857-no-celery Repo: Faction-V/gofigure_terraform Status: APPROVED Mode: Intrapreneurship

Problem Statement

jordotech

ENG-893: Per-Org S3 Access Isolation via Email Domain Verification

Problem

Capitol.ai is a multi-tenant platform where organizations share the same AWS infrastructure. A Capitol.ai admin can add themselves to any organization (e.g., EY) and gain full access to that org's S3 files — uploads, workflow files, and generated outputs. Client orgs need assurance that only users with verified email domains can access their data.

Strategy

We implement email-domain-scoped IAM role assumption — a belt-and-suspenders approach combining STS AssumeRole with explicit IAM Deny policies.

jordotech

Should skills/ Live in a Separate Repo?

TL;DR: The skills/ directory is 3.6MB / 282 files — smaller than a single retina screenshot. Splitting it into a separate repo adds real operational complexity to solve a non-problem, and partially reintroduces the version-coupling failures that caused the outages we're trying to fix.

---

Actual Size of skills/

Total: 3.6 MB, 282 files