WIP - Worktree fxa 13072

.circleci/config.yml

@@ -971,27 +971,18 @@ workflows:
           nx_run: affected --base=main --head=$CIRCLE_SHA1
           projects: --exclude '*,!tag:scope:server:auth'
           start_customs: true
+          resource_class: large
+          target: -t test-integration
           test_suite: servers-auth-integration
           workflow: test_pull_request
           requires:
             - Build (PR)
       - integration-test:
-          name: Integration Test - Servers - Auth V2 (PR)
+          name: Integration Test - Servers - Auth Scripts (PR)
           nx_run: affected --base=main --head=$CIRCLE_SHA1
           projects: --exclude '*,!tag:scope:server:auth'
-          start_customs: true
-          target: -t test-integration-v2
-          test_suite: servers-auth-v2-integration
-          workflow: test_pull_request
-          requires:
-            - Build (PR)
-      - integration-test:
-          name: Integration Test Jest - Servers - Auth (PR)
-          nx_run: affected --base=main --head=$CIRCLE_SHA1
-          projects: --exclude '*,!tag:scope:server:auth'
-          start_customs: true
-          target: -t test-integration-jest
-          test_suite: servers-auth-jest-integration
+          target: -t test-scripts
+          test_suite: servers-auth-scripts
           workflow: test_pull_request
           requires:
             - Build (PR)
@@ -1019,8 +1010,7 @@ workflows:
             - Integration Test - Frontends (PR)
             - Integration Test - Servers (PR)
             - Integration Test - Servers - Auth (PR)
-            - Integration Test - Servers - Auth V2 (PR)
-            - Integration Test Jest - Servers - Auth (PR)
+            - Integration Test - Servers - Auth Scripts (PR)
             - Integration Test - Libraries (PR)
             - Firefox Functional Tests - Playwright (PR)
 
@@ -1182,6 +1172,7 @@ workflows:
           name: Integration Test - Servers - Auth
           projects: --exclude '*,!tag:scope:server:auth'
           start_customs: true
+          target: -t test-integration
           test_suite: servers-auth-integration
           workflow: test_and_deploy_tag
           filters:
@@ -1193,26 +1184,10 @@ workflows:
           requires:
             - Build
       - integration-test:
-          name: Integration Test - Servers - Auth V2
+          name: Integration Test - Servers - Auth Scripts
           projects: --exclude '*,!tag:scope:server:auth'
-          start_customs: true
-          target: -t test-integration-v2
-          test_suite: servers-auth-v2-integration
-          workflow: test_and_deploy_tag
-          filters:
-            branches:
-              ignore: /.*/
-            tags:
-              only: /.*/
-          nx_run: run-many --no-cloud
-          requires:
-            - Build
-      - integration-test:
-          name: Integration Test Jest - Servers - Auth
-          projects: --exclude '*,!tag:scope:server:auth'
-          start_customs: true
-          target: -t test-integration-jest
-          test_suite: servers-auth-jest-integration
+          target: -t test-scripts
+          test_suite: servers-auth-scripts
           workflow: test_and_deploy_tag
           filters:
             branches:
@@ -1311,31 +1286,21 @@ workflows:
           name: Integration Test - Servers - Auth (nightly)
           projects: --exclude '*,!tag:scope:server:auth'
           start_customs: true
+          target: -t test-integration
           test_suite: servers-auth-integration
           workflow: nightly
           nx_run: run-many --skipRemoteCache
           requires:
             - Build (nightly)
       - integration-test:
-          name: Integration Test - Servers - Auth V2 (nightly)
+          name: Integration Test - Servers - Auth Scripts (nightly)
           projects: --exclude '*,!tag:scope:server:auth'
-          start_customs: true
-          target: -t test-integration-v2
-          test_suite: servers-auth-v2-integration
+          target: -t test-scripts
+          test_suite: servers-auth-scripts
           workflow: nightly
           nx_run: run-many --skipRemoteCache
           requires:
             - Build (nightly)
-      - integration-test:
-          name: Integration Test Jest - Servers - Auth (nightly)
-          projects: --exclude '*,!tag:scope:server:auth'
-          start_customs: true
-          target: -t test-integration-jest
-          test_suite: servers-auth-jest-integration
-          workflow: test_pull_request
-          nx_run: run-many --skipRemoteCache
-          requires:
-            - Build (nightly)
       - integration-test:
           name: Integration Test - Libraries (nightly)
           projects: --exclude '*,!tag:scope:shared:*'
@@ -1361,8 +1326,7 @@ workflows:
             - Integration Test - Frontends (nightly)
             - Integration Test - Servers (nightly)
             - Integration Test - Servers - Auth (nightly)
-            - Integration Test - Servers - Auth V2 (nightly)
-            - Integration Test Jest - Servers - Auth (nightly)
+            - Integration Test - Servers - Auth Scripts (nightly)
             - Integration Test - Libraries (nightly)
             - Firefox Functional Tests - Playwright (nightly)
       - create-fxa-image:

.claude/skills/fxa-jira-bug-description/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: fxa-jira-bug-description
+description: Drafts a Jira bug report for an FXA issue. Gathers repro steps, expected vs actual behaviour, and affected surface, then outputs a structured report ready to file or hand to Claude for investigation.
+user-invocable: true
+---
+
+# FXA Jira Bug Report
+
+Draft a Jira bug report for an FXA issue. Output the description only — do not create, edit, or suggest changes to any source files.
+
+## Step 1: Gather Context
+
+If a Sentry link, error log, or stack trace was provided, read it first and infer as much as possible before asking anything.
+
+Required information:
+- **What:** One-sentence description of the bug
+- **Steps to reproduce:** Numbered steps from a known starting state
+- **Expected behaviour:** What should happen
+- **Actual behaviour:** What actually happens
+- **Affected surface:** Which flow, page, or API endpoint; which users or account states are affected
+
+Also useful — ask only for what is missing:
+- Error message, Sentry event, or stack trace
+- Browser, OS, or environment (if frontend)
+- Account state at time of bug (e.g. 2FA enabled, passwordless, linked account)
+- Severity — data loss, security impact, broken flow, visual/cosmetic
+
+If all required information is clear, proceed directly to Step 2.
+
+## Step 2: Research
+
+Search only the packages likely involved. Find:
+- The code path most likely responsible (route handler, component, service method)
+- Any recent changes to that path (`git log` on the relevant files)
+- Whether a similar bug has been fixed before (look for related test cases or comments)
+
+Incorporate findings directly into Root Cause and Key Reference Files. Surface genuine unknowns as Open Questions.
+
+## Step 3: Output
+
+**Summary:** `[area] <concise bug description>` — e.g. `[auth] Passkey registration fails silently when device has no authenticator`
+
+**Background:**
+What the bug is, where it occurs, and who is affected. 2–3 sentences.
+
+**Steps to Reproduce:**
+Numbered steps from a known starting state. Include account state and environment where relevant.
+
+**Expected Behaviour:**
+What should happen.
+
+**Actual Behaviour:**
+What actually happens. Include error message, code, or Sentry event if available.
+
+**Affected Surface:**
+Which users, flows, account states, browsers, or environments are affected. Note if intermittent.
+
+**Severity:** *(Critical / High / Medium / Low)*
+- Critical — data loss, security vulnerability, auth bypass
+- High — broken core flow affecting multiple users
+- Medium — degraded experience, workaround exists
+- Low — cosmetic, edge case, minor inconvenience
+
+**Root Cause:** *(if known or suspected — omit if unknown)*
+Where in the code the bug originates. Reference specific file and function if identified.
+
+**Acceptance Criteria:**
+- Bug is no longer reproducible following the steps above
+- Regression test added covering the broken path
+- *(add any additional observable outcomes)*
+
+**Key Reference Files:**
+Specific files relevant to investigation or fix. One line each.
+
+**Out of Scope:** *(omit if not needed)*
+
+**Open Questions:** *(omit if none)*
+
+## Guidelines
+
+- Output the description only — no source file changes
+- Steps to Reproduce must be precise enough for another engineer to reproduce independently
+- Do not speculate on root cause unless there is clear evidence — use Open Questions instead
+- Severity should reflect user impact, not code complexity
+- Always include a regression test in Acceptance Criteria
+- If the bug has security implications (auth bypass, data exposure, token leakage), flag severity as Critical and note it explicitly in Background

.claude/skills/fxa-jira-feature-description/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: fxa-jira-feature-description
+description: Drafts a concise Jira description for an FXA task. Gathers context via targeted interview, researches relevant patterns in the repo, then outputs a clean description ready for an engineer to hand to Claude for implementation.
+user-invocable: true
+---
+
+# FXA Jira Description
+
+Draft a Jira description for an FXA task. Output the description only — do not create, edit, or suggest changes to any source files.
+
+## Step 1: Gather Context
+
+If a planning doc, epic description, or tech spec was provided, read it first and infer what, why, packages, and constraints before asking anything.
+
+Required information:
+- **What:** What is being built or changed, in one sentence
+- **Why:** Motivation — user need, requirement, bug, or tech debt
+- **Packages:** Which specific package(s) will be modified (e.g. `fxa-auth-server`, `libs/accounts/passkey`)
+- **Constraints:** Feature flag, breaking change, migration, L10n — or none
+
+If all four are clear from provided context, proceed directly to Step 2. Otherwise ask for only what is missing in a single message. Also invite related PRs, tickets, existing approach notes, design mockups, or flow diagrams that would add useful context.
+
+## Step 2: Research
+
+Search only the packages identified in Step 1. Find the most relevant existing patterns: similar feature, nearby route, equivalent component. Expand to the broader repo only if nothing relevant is found there.
+
+Identify:
+- Key files an implementer will need to touch
+- The closest existing reference implementation to follow
+- Whether tests, metrics, or security events apply (see Step 3)
+
+Incorporate findings directly into the draft — do not list them separately or ask for confirmation. Surface genuine blockers as Open Questions.
+
+## Step 3: Output
+
+**Design:** *(Figma link if applicable. Note that all copy, strings, and visual specs should be taken from the latest Figma file — do not reproduce design details here as they may change before implementation. Omit if no design involved.)*
+
+**Background:**
+Why this is needed and what it enables. 2–4 sentences.
+
+**Acceptance Criteria:**
+Observable, testable outcomes. Each item verifiable without reading the code. Include criteria for tests, metrics emission, and security events where applicable to this task.
+
+**Implementation Steps:**
+Numbered steps with file paths, method names, and structural guidance. Reference the nearest existing pattern for each step. No code snippets — file locations, types, and patterns only.
+
+**Tests:**
+What needs to be tested. Unit, integration, and snapshot coverage expectations. Reference the nearest existing test file as a pattern. Omit if covered inline above.
+
+**Metrics & Security Events:** *(omit if not applicable)*
+Any StatsD metrics or security events (`log.info`, `request.emitMetricsEvent`, `customs` checks) that should be emitted. Reference the nearest equivalent for naming conventions.
+
+**Key Reference Files:**
+Specific files the implementer should read before starting. One line each.
+
+**Out of Scope:** *(omit if not needed)*
+
+**Open Questions:** *(omit if none)*
+
+## Guidelines
+
+- Output the description only — no source file changes
+- Implementation Steps should give enough detail to start work without follow-up questions — file paths and patterns, not prose
+- Do not include design details (copy, colours, layout, component specifics) — note that the implementer should refer to the latest Figma file
+- Omit redundant or obvious acceptance criteria
+- Include Tests, Metrics & Security Events sections only when relevant to the task type
+- If motivation or scope remain unclear after asking, flag as an Open Question rather than assuming

.claude/skills/fxa-review/SKILL.md

@@ -51,6 +51,7 @@ Tell this agent it is a senior security engineer. It should:
 - Check CORS configuration — no `*` on credentialed endpoints
 - Verify OTP/TOTP handling: constant-time comparison, immediate invalidation, rate limiting
 - Check that secrets are accessed via Convict config, not hardcoded or read from env directly
+- Check StatsD metric tags for unbounded cardinality: user-controlled values (clientId, email, service) used as metric tags must be validated against a known allowlist (e.g. `getRegisteredClientIds()` or `getClientServiceTags(request)`). Free-form strings as tags allow attackers to blow up Prometheus storage.
 
 Output JSON array with fields: severity, category ("Security"), subcategory, file, line, issue, recommendation.
 

.claude/skills/fxa-simplify/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: fxa-simplify
 description: Simplifies and refines code in the FXA monorepo using project-specific conventions. Use when asked to simplify, clean up, or refine recently written code. Focuses on recently modified code unless instructed otherwise.
+argument-hint: Optional file paths to scope the review (e.g. "packages/fxa-auth-server/lib/foo.ts")
 context: fork
 ---
 
@@ -103,16 +104,22 @@ Avoid over-simplification that could:
 
 ## 7. Focus Scope
 
-Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope.
+**Only refine lines that were actually changed in the diff.** Do not refine unchanged surrounding code, even if it could be improved. The goal is to keep the diff minimal and focused.
+
+- If file paths are provided via `$ARGUMENTS`, scope to those files only
+- Otherwise, run `git diff HEAD~1..HEAD --name-only` to find changed files, then `git diff HEAD~1..HEAD` to see the line-level changes
+- Within each file, only refine the lines that appear in the diff (added or modified lines), not the entire file
+- Exception: if a changed line introduces an obvious bug or inconsistency with adjacent unchanged code, note it but do not fix the unchanged code without asking
 
 ## Refinement Process
 
-1. Identify the recently modified code sections
-2. Determine which package/domain the code belongs to (auth-server, settings, libs, etc.)
-3. Apply the appropriate conventions for that domain
-4. Analyze for opportunities to improve elegance and consistency
-5. Ensure all functionality remains unchanged
-6. Verify the refined code is simpler and more maintainable
-7. Document only significant changes that affect understanding
+1. If `$ARGUMENTS` contains file paths, use those. Otherwise run `git diff HEAD~1..HEAD --name-only` to find changed files.
+2. Run `git diff HEAD~1..HEAD` to see the actual line-level changes
+3. For each changed file, only analyze and refine the lines that were added or modified in the diff
+4. Determine which package/domain the code belongs to (auth-server, settings, libs, etc.)
+5. Apply the appropriate conventions for that domain to the changed lines only
+6. Ensure all functionality remains unchanged
+7. Verify the refined code is simpler and more maintainable
+8. Document only significant changes that affect understanding
 
 Your goal is to ensure all code meets the highest standards of elegance and maintainability while preserving its complete functionality.