create-ai-project 1.20.9 → 1.22.0

package/.claude/skills-en/frontend-typescript-testing/references/e2e.md

@@ -1,5 +1,16 @@
 # E2E Test Implementation with Playwright
 
+## Lane Selection
+
+E2E tests in this workflow split into two lanes (defined in integration-e2e-testing skill):
+
+| Lane | Backend setup | Use these patterns |
+|------|---------------|-------------------|
+| **fixture-e2e** | Mocked via `page.route()` or fixture loaders; no live services | Page Object Pattern, Locator Strategy, Assertions, the **Fixture-Based Backend** section below |
+| **service-integration-e2e** | Live local stack with real services | All patterns above PLUS a real auth fixture against the application's login flow and seeded test data |
+
+The skeleton's `@lane:` annotation declares which lane the test belongs to. Choose implementation patterns to match.
+
 ## Test Framework
 - **Playwright Test**: `@playwright/test`
 - Test imports: `import { test, expect } from '@playwright/test'`
@@ -10,18 +21,23 @@
 ```
 tests/
 └── e2e/
-    ├── pages/              # Page objects
+    ├── pages/                       # Page objects (shared across lanes)
     │   ├── login.page.ts
     │   └── dashboard.page.ts
-    ├── fixtures/           # Test fixtures
+    ├── fixtures/                    # Test fixtures (auth, seed)
     │   └── auth.fixture.ts
-    └── *.e2e.test.ts       # Test files
+    ├── data/                        # Static fixture data for fixture-e2e
+    │   └── *.fixture.json
+    ├── *.fixture-e2e.test.ts        # fixture-e2e test files
+    └── *.service-e2e.test.ts        # service-integration-e2e test files
 ```
 
 ### Naming Conventions
-- Test files: `{FeatureName}.e2e.test.ts`
+- fixture-e2e files: `{FeatureName}.fixture-e2e.test.ts`
+- service-integration-e2e files: `{FeatureName}.service-e2e.test.ts`
 - Page objects: `{PageName}.page.ts`
 - Fixtures: `{Purpose}.fixture.ts`
+- Static fixture data: `{scenario}.fixture.json`
 
 ## Page Object Pattern
 
@@ -102,6 +118,59 @@ export const test = base.extend<{ authenticatedPage: Page }>({
 })
 ```
 
+## Fixture-Based Backend (fixture-e2e)
+
+fixture-e2e tests run a real browser against deterministic fixtures — no live backend, no DB, no external services. Use one of these patterns to fake the network:
+
+### Pattern A: page.route() interception
+
+```typescript
+import { test, expect } from '@playwright/test'
+import cardsFixture from './data/cards.fixture.json'
+
+test('Dismiss-then-Undo restores card', async ({ page }) => {
+  // Arrange: intercept all backend calls with deterministic responses
+  await page.route('**/api/cards', async (route) => {
+    await route.fulfill({ json: cardsFixture })
+  })
+  await page.route('**/api/cards/*/dismiss', async (route) => {
+    await route.fulfill({ status: 204 })
+  })
+
+  await page.goto('/cards')
+  await page.getByRole('button', { name: 'Dismiss' }).first().click()
+  await page.getByRole('button', { name: 'Undo' }).click()
+
+  await expect(page.getByText(cardsFixture[0].title)).toBeVisible()
+})
+```
+
+### Pattern B: Fixture loader injection
+
+```typescript
+// data/cards-with-dismiss.fixture.json — committed alongside the test
+// Loaded via a route helper or app-level test mode
+```
+
+**Principles for fixture-e2e**:
+- Backend is faked, not running. No `npm run start:backend` required to execute these tests
+- Fixtures are versioned in the repo (`tests/e2e/data/`) so tests are deterministic across machines
+- Auth, when needed, is faked too (set a test cookie via `page.context().addCookies()` or use a fixture-mode bypass)
+- These tests run in CI without provisioning external infrastructure
+
+## E2E Environment Prerequisites (service-integration-e2e only)
+
+service-integration-e2e tests require a running application with real data state. Unlike fixture-e2e, environment setup is part of test implementation scope.
+
+Before service-integration-e2e tests can pass, verify:
+- [ ] Application is running and accessible at `baseURL`
+- [ ] Database has required seed data (test users, required records)
+- [ ] Authentication flow works with test credentials against the real auth flow
+- [ ] Environment variables are set (`E2E_*` prefixed)
+- [ ] External services are either available or stubbed
+
+When the work plan includes dedicated environment setup tasks (Phase 0), follow those tasks. When no setup tasks exist in the plan, address missing prerequisites as part of the test implementation task itself, OR consider whether the verification could move to fixture-e2e instead.
+
 ## Locator Strategy
 
 Prefer accessible locators in this order:
@@ -168,13 +237,14 @@ test.describe('responsive navigation', () => {
 
 ## Skeleton Comment Format
 
-E2E test skeletons follow the same annotation format as integration tests:
+E2E test skeletons follow the same annotation format as integration tests, with a required `@lane:` annotation declaring the lane (see Lane Selection above):
 
 ```typescript
 // AC: [Original acceptance criteria text]
 // Behavior: [User action] → [System response] → [Observable result]
-// @category: e2e
-// @dependency: full-system
+// @category: fixture-e2e | service-integration-e2e
+// @lane: fixture-e2e | service-integration-e2e
+// @dependency: full-ui (mocked backend) | full-system
 // @complexity: high
 // ROI: [score]
 test('AC1: [Description]', async ({ page }) => {
@@ -183,3 +253,7 @@ test('AC1: [Description]', async ({ page }) => {
   // Assert: [Verification description]
 })
 ```
+
+**`@dependency` selection by lane**:
+- `fixture-e2e` → `@dependency: full-ui (mocked backend)` (no live services; intercept network via `page.route()` or fixture loaders)
+- `service-integration-e2e` → `@dependency: full-system` (running local stack required)

package/.claude/skills-en/integration-e2e-testing/SKILL.md

@@ -12,10 +12,17 @@ description: Designs integration and E2E tests with mock boundaries and behavior
 
 ## Test Types and Limits
 
-| Type | Purpose | File Format | Limit |
-|------|---------|-------------|-------|
-| Integration Test | Component interaction verification | `*.int.test.ts` | 3 per feature |
-| E2E Test | Critical user journey verification | `*.e2e.test.ts` | 1-2 per feature |
+| Test Type | Purpose | Scope | External Deps | File Format | Limit per Feature | Implementation Timing |
+|-----------|---------|-------|---------------|-------------|-------------------|----------------------|
+| Integration | Verify component interactions in-process | Partial system integration (in-process modules; for UI components, RTL+MSW for React/TS) | Mocked or in-process | `*.int.test.ts` | MAX 3 | Created alongside implementation |
+| fixture-e2e | Verify UI behavior in a browser with deterministic fixtures | Full UI flow with mocked backend / fixture-driven state | Mocked / fixture only — no live services | `*.fixture-e2e.test.ts` | MAX 3 | Created alongside the UI feature |
+| service-integration-e2e | Verify critical user journeys against a running local stack | Full system across services | Live local services or stubs | `*.service-e2e.test.ts` | MAX 1-2 | Executed only in the final phase |
+
+**Lane selection (E2E only)**:
+- Default lane for user-facing UI journeys is **fixture-e2e** — it runs a real browser against deterministic fixtures, catches the bugs that unit/integration tests miss (button no-op, state never updates, navigation breaks), and runs in CI without infrastructure setup
+- Add **service-integration-e2e** only when the journey's correctness depends on real cross-service behavior (data persistence, transactional consistency, external service contracts) that cannot be faked safely
+
+The two E2E lanes are budgeted independently — having a fixture-e2e for a journey does not consume the service-integration-e2e budget and vice versa.
 
 **Critical User Journey**: Features with revenue impact, legal requirements, or daily use by majority of users
 
@@ -44,12 +51,18 @@ Each test MUST include the following annotations.
 // AC: "[Acceptance criteria original text]"
 // ROI: [0-100] | Business Value: [0-10] | Frequency: [0-10]
 // Behavior: [Trigger] -> [Process] -> [Observable Result]
-// @category: core-functionality | integration | edge-case | ux | e2e
-// @dependency: none | [component name] | full-system
+// @category: core-functionality | integration | edge-case | ux | fixture-e2e | service-integration-e2e
+// @lane: integration | fixture-e2e | service-integration-e2e
+// @dependency: none | [component names] | full-ui (mocked backend) | full-system
 // @complexity: low | medium | high
 // @real-dependency: [component name] (optional, when Test Boundaries specify non-mock setup)
 ```
 
+**`@lane` selection rule**:
+- `integration` — Component interaction in-process, no browser (e.g., RTL+MSW for React/TS, in-process module/handler integration in any language)
+- `fixture-e2e` — Browser-level UI verification with mocked backend / fixture-driven state. `@dependency` is typically `full-ui (mocked backend)`
+- `service-integration-e2e` — Browser-level or end-to-end verification against running local services or stubs. `@dependency` is `full-system`
+
 ### Property Annotations
 
 ```typescript
@@ -71,17 +84,14 @@ A feature qualifies as containing a **multi-step user journey** when ALL of the
 
 ### User-Facing vs Service-Internal Journeys
 
-Multi-step journeys are further classified for E2E budget decisions:
+Multi-step journeys are classified for reserved-slot eligibility:
 
-| Classification | Condition | E2E Reserved Slot | Example |
+| Classification | Condition | Reserved Slot Eligibility | Example |
 |---|---|---|---|
-| **User-facing** | A human user directly triggers and observes the steps (via UI, CLI, or direct API interaction) | Eligible | Web checkout flow, CLI setup wizard, mobile onboarding |
-| **Service-internal** | Steps are triggered by backend services without direct user interaction | Not eligible for reserved slot | Async job pipeline, service-to-service saga, scheduled batch processing |
+| **User-facing** | A human user directly triggers and observes the steps (via UI, CLI, or direct API interaction) | Eligible — defaults to **fixture-e2e** reserved slot. Add a service-integration-e2e reserved slot only when the journey's correctness depends on real cross-service behavior | Web checkout flow, CLI setup wizard, mobile onboarding |
+| **Service-internal** | Steps are triggered by backend services without direct user interaction | Not eligible for reserved slot — use integration tests. service-integration-e2e through normal ROI > 50 path is still valid when full-system verification is warranted | Async job pipeline, service-to-service saga, scheduled batch processing |
 
-**Scope of this classification**:
-- **Reserved E2E slot**: Only user-facing journeys qualify. Service-internal journeys are excluded from the reserved slot.
-- **Normal ROI > 50 path**: Both user-facing and service-internal journeys compete for the additional E2E slot (up to 1) on ROI merit alone. Classification does not affect this path.
-- **E2E Gap Check**: Only user-facing journeys trigger the gap warning. Service-internal journeys do not.
+This classification applies to the reserved-slot rule and the E2E Gap Check. Other selection follows lane-specific ROI rules below.
 
 ### ROI Calculation
 
@@ -94,20 +104,29 @@ ROI Score = Business Value × User Frequency + Legal Requirement × 10 + Defect
 
 Higher ROI Score = higher priority within its test type. No normalization or capping is applied — the raw score is used directly for ranking. Deduplication is a separate step that removes candidates entirely; it does not modify scores.
 
-### ROI Threshold for E2E
+### ROI Thresholds by Lane
 
-E2E tests have high ownership cost (creation, execution, and maintenance are each 3-10× higher than integration tests). To justify creation, an E2E candidate (beyond the must-keep reserved slot) requires **ROI Score > 50**.
+The two E2E lanes have very different ownership costs and use independent thresholds.
+
+| Lane | ROI threshold | Rationale |
+|------|---------------|-----------|
+| fixture-e2e | ROI ≥ 20 (beyond reserved slot) | Cost is comparable to integration tests once the harness exists; the floor avoids filling MAX 3 with low-signal tests when fewer would suffice |
+| service-integration-e2e | ROI > 50 (beyond reserved slot) | Creation, execution, and maintenance cost is 3-10× higher than integration; reserve for journeys whose value cannot be proven any other way |
+
+Reserved slot rules apply per lane and override the threshold (the reserved candidate is emitted regardless of its ROI score). Below-floor candidates beyond the reserved slot are not emitted, leaving budget intentionally unfilled rather than padding with low-value tests.
 
 ### ROI Calculation Examples
 
 | Scenario | BV | Freq | Legal | Defect | ROI Score | Test Type | Selection Outcome |
 |----------|----|------|-------|--------|-----------|-----------|-------------------|
-| Core checkout flow | 10 | 9 | true | 9 | 109 | E2E | Selected (reserved slot: user-facing multi-step journey) |
-| Payment error handling | 8 | 3 | false | 7 | 31 | E2E | Below threshold (31 < 50), not selected |
-| Profile save flow | 7 | 6 | false | 6 | 48 | E2E | Below threshold (48 < 50), not selected |
+| Core checkout UI flow | 10 | 9 | true | 9 | 109 | fixture-e2e | Selected (reserved slot: user-facing multi-step journey, browser verification with fixtures) |
+| Core checkout against live payment service | 10 | 9 | true | 9 | 109 | service-integration-e2e | Selected (real-service correctness above ROI threshold) |
+| Dismiss button updates UI state | 6 | 7 | false | 8 | 50 | fixture-e2e | Selected (rank 2 of 3 fixture-e2e budget) |
+| Payment error message display (UI) | 5 | 4 | false | 7 | 27 | fixture-e2e | Selected (rank 3 of 3 fixture-e2e budget) |
+| Optional filter toggle | 3 | 4 | false | 2 | 14 | fixture-e2e | Not selected (rank 4, budget full) |
+| Payment retry against real provider | 8 | 3 | false | 7 | 31 | service-integration-e2e | Below ROI threshold (31 < 50), not selected |
 | DB persistence check | 8 | 8 | false | 8 | 72 | Integration | Selected (rank 1 of 3) |
-| Error message display | 5 | 3 | false | 4 | 19 | Integration | Selected (rank 2 of 3) |
-| Optional filter toggle | 3 | 4 | false | 2 | 14 | Integration | Not selected (rank 4, budget full) |
+| Pure data transformation | 5 | 3 | false | 4 | 19 | Integration | Selected (rank 2 of 3) |
 
 ## Implementation Rules
 
@@ -169,8 +188,14 @@ it('AC2-property: Model name is always gemini-3-pro-image-preview', () => {
 
 ### E2E Test Execution Conditions
 
-- Execute only after all components are implemented
-- Do not use mocks (`@dependency: full-system`)
+**fixture-e2e**:
+- Execute alongside the UI feature implementation phase (not deferred to the end)
+- Use mocked backend / fixture-driven state (`@dependency: full-ui (mocked backend)`); no live services required
+- Runs in CI without infrastructure setup
+
+**service-integration-e2e**:
+- Execute only in the final phase, after all components are implemented and the local stack is up
+- Use real local services or service stubs — no in-process mocks for the components under verification (`@dependency: full-system`)
 
 ## Review Criteria
 

package/.claude/skills-en/integration-e2e-testing/references/e2e-design.md

@@ -1,8 +1,21 @@
-# E2E Test Design with Playwright
+# E2E Test Design (Browser Harness)
+
+This reference uses Playwright as the default example throughout because it is the standard E2E browser harness assumed by these workflows. Adapt patterns to the project's chosen framework when different (Cypress, Selenium, etc.); the lane definitions, ROI rules, and budgets remain the same.
+
+## Two E2E Lanes
+
+E2E tests in this workflow split into two lanes (see parent skill Test Types and Limits):
+
+| Lane | When | ROI gate | Cost |
+|------|------|----------|------|
+| **fixture-e2e** | UI journey verification with deterministic fixtures (mocked backend / fixture data) | Reserved slot is exempt; additional slots within MAX 3 require ROI ≥ 20 | Comparable to integration; runs in CI without infrastructure setup |
+| **service-integration-e2e** | Journey correctness depends on real cross-service behavior (data persistence, transactional consistency, external contracts) | ROI > 50 (beyond reserved slot) | 3-10× higher than integration; reserved for what cannot be faked safely |
+
+Both lanes typically use Playwright; the difference is whether the backend is mocked / fixture-driven or running for real.
 
 ## When to Create E2E Tests
 
-E2E tests target **critical user journeys** that span multiple pages or require real browser interaction. Apply the same ROI framework from the parent skill — only create E2E tests when ROI > 50.
+E2E candidates target **critical user journeys** that span multiple pages or require real browser interaction. Pick the lane based on whether real services are required for the verification.
 
 ### Candidate Sources
 
@@ -21,10 +34,10 @@ E2E tests target **critical user journeys** that span multiple pages or require
 - Accessibility verification requiring actual DOM rendering
 - Responsive behavior across viewports
 
-**Exclude** (use integration tests instead):
-- Single-component state changes (use RTL)
-- API response handling (use MSW + RTL)
-- Pure data transformations
+**Use integration tests instead when**:
+- Testing single-component state changes → in-process component renderer (RTL for React/TS)
+- Testing API response handling → in-process API mock + component renderer (MSW + RTL for React/TS)
+- Testing pure data transformations → unit tests
 
 ## UI Spec to E2E Test Mapping
 
@@ -41,12 +54,15 @@ When a UI Spec exists, use it as the primary source for E2E test design:
 Screen Transition: [Screen A] → [Screen B] → [Screen C]
 AC Reference: AC-{id}
 User Journey: [Description of what the user accomplishes]
-Preconditions: [Auth state, data state]
+Lane: fixture-e2e | service-integration-e2e
+Preconditions: [Auth state, data state — note whether these are fixture-driven or live]
 Verification Points:
   - [What to assert at each step]
 E2E ROI Score: [calculated score]
 ```
 
+**Lane decision**: choose `fixture-e2e` by default. Promote to `service-integration-e2e` when the verification requires observing real cross-service behavior (e.g., the test asserts that data persists across a real DB write, or that an external service receives the correct payload).
+
 ## Playwright Test Architecture
 
 ### Page Object Pattern
@@ -56,9 +72,11 @@ Organize browser interactions through page objects for maintainability:
 ```
 tests/
 ├── e2e/
-│   ├── pages/           # Page objects
-│   ├── fixtures/        # Test fixtures and helpers
-│   └── *.e2e.test.ts    # Test files
+│   ├── pages/                       # Page objects (shared across lanes)
+│   ├── fixtures/                    # Test fixtures and helpers (auth, seed)
+│   ├── data/                        # Static fixture data for fixture-e2e
+│   ├── *.fixture-e2e.test.ts        # fixture-e2e test files
+│   └── *.service-e2e.test.ts        # service-integration-e2e test files
 ```
 
 ### Test Isolation
@@ -81,6 +99,6 @@ When UI Spec defines responsive behavior, test critical breakpoints:
 ## Budget Enforcement
 
 Hard limits per feature (same as parent skill):
-- **E2E Tests**: MAX 1-2 tests
-- Only generate if ROI score > 50
-- Prefer fewer, comprehensive journey tests over many granular tests
+- **fixture-e2e**: MAX 3 tests. Reserved slot is exempt from the ROI gate; additional slots require ROI ≥ 20
+- **service-integration-e2e**: MAX 1-2 tests, ROI > 50 beyond the reserved slot
+- Prefer fewer, comprehensive journey tests over many granular tests in both lanes

package/.claude/skills-en/project-context/SKILL.md

@@ -1,21 +1,8 @@
 ---
 name: project-context
-description: Provides project-specific prerequisites for AI execution accuracy. Use when checking project structure.
+description: Provides project-specific prerequisites for AI execution accuracy — domain constraints, development phase, directory conventions, external resource access methods. Use when the session starts, when checking project structure, or when a task references domain rules or external resources outside the repository.
 ---
 
 # Project Context
 
-> **Not configured.** Run `/project-inject` to set up project-specific context.
-
-## Project Overview
-- **What this project does**: (to be configured)
-- **Domain**: (to be configured)
-
-## Domain Constraints
-(Domain-specific rules that affect AI decision-making)
-
-## Development Phase
-- **Phase**: (Prototype / Production / In operation)
-
-## Directory Conventions
-(File placement rules, if any)
+Run `/project-inject` to populate this skill.

package/.claude/skills-en/project-context/references/external-resources-api.md

@@ -0,0 +1,76 @@
+# API Contract External Resource Axes
+
+Hearing axes for API contract design, client integration, or server endpoint implementation. `/project-inject` loads this file when the user selects the API domain.
+
+## Axis 1: API Schema Source
+
+The canonical source of API contracts (request/response shapes, endpoints, RPC methods).
+
+**AskUserQuestion choices**:
+- OpenAPI / Swagger specification (file in repository or hosted URL)
+- Protobuf definitions (file in repository)
+- GraphQL schema (SDL file or introspection endpoint)
+- Code-first contract definitions in the repository (e.g., TypeScript types shared between client and server)
+- Ad-hoc JSON (no formal contract)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: file path or URL.
+- **Access method**: file read or WebFetch.
+
+When multiple contracts exist (public API, internal services), capture each as a separate entry per the multiple-instance rule in `template.md`, using the contract purpose as the disambiguating suffix.
+
+## Axis 2: Mock Environment
+
+How clients exercise the API in isolation from the live server.
+
+**AskUserQuestion choices**:
+- Generated mocks from the schema (e.g., from OpenAPI / Protobuf tooling)
+- Hand-written mock server in the repository
+- Hosted mock service (URL)
+- Live development server (no separate mock)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: mock URL or repository path.
+- **Access method**: CLI command, WebFetch, or generation step name. State whether the mock auto-updates when the schema changes (e.g., `regenerate from openapi.yaml on commit`).
+
+## Axis 3: Authentication Method
+
+How the API authenticates and authorizes requests.
+
+**AskUserQuestion choices**:
+- Bearer token (e.g., JWT) issued by an auth service
+- API key in a header or query parameter
+- Session cookie set by a separate login flow
+- Mutual TLS
+- No authentication
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: auth service URL, environment variable name, or fixture file path used in development and testing.
+- **Access method**: SDK call, CLI command, or file read.
+
+When the same secrets live in the backend secret store, render this axis as a cross-axis reference back to that location (notation defined in `template.md`).
+
+## Axis 4: Schema Change Process
+
+How breaking and non-breaking schema changes are reviewed and rolled out.
+
+**AskUserQuestion choices**:
+- Documented contract review process (link to the document)
+- Versioned endpoints (e.g., `/v1/`, `/v2/`)
+- Backward-compatible changes only, no formal versioning
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: document path or URL.
+- **Access method**: file read, WebFetch, or version negotiation rule statement (e.g., `breaking changes require a new /vN/ path`).
+
+## Self-Declaration Phase
+
+After the four structured axes, ask once: "Are there any other API external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
+
+Capture free-form answers under the "Additional Resources" subsection of the API block. Run this phase even when every structured axis returned "Not applicable".
+
+Examples of resources that surface only via self-declaration: rate-limit configuration, gateway or proxy in front of the API, contract test suite (e.g., Pact broker URL), API gateway management consoles, third-party API documentation consulted during design.

package/.claude/skills-en/project-context/references/external-resources-backend.md

@@ -0,0 +1,76 @@
+# Backend External Resource Axes
+
+Hearing axes for server-side, data, or storage work. `/project-inject` loads this file when the user selects the Backend domain.
+
+## Axis 1: Database Schema Source
+
+The canonical source of the database schema (tables, columns, indexes, constraints).
+
+**AskUserQuestion choices**:
+- Migration files in the repository (e.g., a `migrations/` directory)
+- Schema file in the repository (e.g., `schema.sql`, `prisma/schema.prisma`)
+- Database MCP server that introspects a live database
+- External schema registry (URL or hosted catalog)
+- No persistent database
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: file path, URL, or MCP target identifier.
+- **Access method**: file read, WebFetch, or MCP server name.
+
+When multiple databases exist (primary, analytics, cache), capture each as a separate entry per the multiple-instance rule in `template.md`, using the database purpose as the disambiguating suffix.
+
+## Axis 2: Migration History
+
+How schema changes are tracked over time.
+
+**AskUserQuestion choices**:
+- Versioned migration files in the repository
+- ORM-managed migration tool (e.g., Alembic, Flyway, Prisma Migrate)
+- Manual change log document
+- No migration tracking
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: directory path or migration tool name.
+- **Access method**: CLI command for manual runs, or CI step / deployment hook name when migrations apply automatically.
+
+## Axis 3: Secret Store
+
+Where credentials, API keys, and other secrets are stored and accessed.
+
+**AskUserQuestion choices**:
+- Secret manager service (e.g., AWS Secrets Manager, Vault, GCP Secret Manager)
+- Environment variables loaded from a `.env` file (development only)
+- Encrypted file in the repository
+- No secrets required
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: secret manager service name or MCP target.
+- **Access method**: MCP server name, CLI command, or SDK call used to read secrets.
+
+The actual secret values live in the store and are read from there at runtime — capture only how to reach them.
+
+## Axis 4: Background Job Infrastructure
+
+How asynchronous work is dispatched and observed.
+
+**AskUserQuestion choices**:
+- Queue service (e.g., SQS, Pub/Sub, RabbitMQ)
+- Cron / scheduled tasks managed by the deployment platform
+- In-process worker thread
+- No background work
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: queue name or scheduler identifier.
+- **Access method**: enqueue command, inspect command, or platform console URL.
+
+## Self-Declaration Phase
+
+After the four structured axes, ask once: "Are there any other backend external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
+
+Capture free-form answers under the "Additional Resources" subsection of the Backend block. Run this phase even when every structured axis returned "Not applicable".
+
+Examples of resources that surface only via self-declaration: third-party SaaS APIs (payment, email, search index), distributed cache services (Redis, Memcached), object storage (S3, GCS), feature flag services consumed server-side, observability platforms (logs, traces, metrics).

package/.claude/skills-en/project-context/references/external-resources-frontend.md

@@ -0,0 +1,74 @@
+# Frontend External Resource Axes
+
+Hearing axes for frontend work — component implementation, screen design, visual adjustment, design system migration. `/project-inject` loads this file when the user selects the Frontend domain.
+
+## Axis 1: Design Origin
+
+The canonical source of the visual specification.
+
+**AskUserQuestion choices**:
+- Design tool (a hosted design platform)
+- Specification file in the repository (e.g., `DESIGN.md`, `docs/design/...`)
+- Public documentation URL
+- Existing implementation only (no separate design source)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields (Source type is set by the choice above):
+- **Location**: public URL, repository file path, or MCP target identifier.
+- **Access method**: WebFetch, file read, MCP server name, or manual screenshot procedure.
+
+## Axis 2: Design System
+
+Reusable component library and design tokens.
+
+**AskUserQuestion choices**:
+- Component library with MCP server access
+- Component library with documentation URL
+- Storybook or equivalent component catalog
+- Internal package with team-internal documentation only
+- No design system (ad-hoc components)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: Storybook URL, package name, or internal documentation path.
+- **Access method**: WebFetch, file read, or MCP server name.
+
+## Axis 3: Guidelines
+
+Usage guidance, accessibility rules, anti-patterns, naming conventions for UI work.
+
+**AskUserQuestion choices**:
+- Project-level guideline file (e.g., `DESIGN.md`, `docs/guidelines/...`)
+- External documentation site
+- Inline guidance inside the design system catalog
+- No documented guidelines
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: file path or URL.
+- **Access method**: file read or WebFetch.
+
+When multiple files address different concerns (CSS, accessibility, i18n), capture each as a separate entry per the multiple-instance rule in `template.md`.
+
+## Axis 4: Visual Verification Environment
+
+How rendered output is confirmed during implementation.
+
+**AskUserQuestion choices**:
+- End-to-end test runner with screenshot capability
+- Storybook or equivalent isolated component preview
+- Browser automation tool (dedicated CLI or MCP server)
+- Manual browser inspection only
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: preview URL, MCP target, or test runner identifier.
+- **Access method**: entry command, MCP server name, or browser automation tool name.
+
+## Self-Declaration Phase
+
+After the four structured axes, ask once: "Are there any other frontend external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
+
+Capture free-form answers under the "Additional Resources" subsection of the Frontend block. Run this phase even when every structured axis returned "Not applicable".
+
+Examples of resources that surface only via self-declaration: brand asset CDNs, font hosting services, icon library subscriptions, A/B testing dashboards that gate visual variants, analytics dashboards consulted for visual KPIs.