wangyizhe/his
1
3
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity

fix(security): 添加VITE_PAYMENT_URL环境变量配置

Browse Source
This commit is contained in:
chenqi
2026-06-18 21:29:41 +08:00
parent 3d977d0a2d
commit 8afeb2e4d9
160 changed files with 21893 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
.qoder/skills/understand/frameworks/django.md Normal file
View File

@@ -0,0 +1,67 @@
# Django Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Django is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Django Project Structure
When analyzing a Django project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `manage.py` | CLI entry point for dev server, migrations, management commands | `entry-point`, `config` |
| `*/settings.py`, `*/settings/*.py` | Project-wide configuration (DB, installed apps, middleware) | `config` |
| `*/urls.py` | URL routing — maps URL patterns to views | `api-handler`, `routing` |
| `*/views.py`, `*/views/*.py` | Request handlers (function-based or class-based views) | `api-handler`, `controller` |
| `*/models.py`, `*/models/*.py` | ORM models — map to database tables | `data-model` |
| `*/serializers.py` | DRF serializers — convert models to/from JSON | `serialization`, `api-handler` |
| `*/forms.py` | Django forms — validation and rendering logic | `validation`, `ui` |
| `*/admin.py` | Admin site registrations — exposes models in Django admin | `config` |
| `*/signals.py` | Signal handlers — cross-cutting side effects on model events | `event-handler` |
| `*/tasks.py` | Celery async task definitions | `service`, `event-handler` |
| `*/middleware.py`, `*/middleware/*.py` | Request/response middleware classes | `middleware` |
| `*/permissions.py` | DRF permission classes | `middleware`, `validation` |
| `*/filters.py` | DRF filter backends | `utility` |
| `*/migrations/*.py` | Auto-generated schema migrations — do not summarize individually | `config` |
| `*/templates/**/*.html` | Django HTML templates | `ui` |
| `*/templatetags/*.py` | Custom template filters and tags | `utility` |
| `*/management/commands/*.py` | Custom management commands (`./manage.py mycommand`) | `config`, `entry-point` |
| `wsgi.py`, `asgi.py` | WSGI/ASGI server adapter — production entry point | `config`, `entry-point` |
| `*/apps.py` | App configuration and startup hooks (`AppConfig`) | `config` |
| `*/tests.py`, `*/tests/*.py` | Unit and integration tests | `test` |
### Edge Patterns to Look For
**URL routing graph** — Create `calls` edges from `urls.py` nodes to their corresponding view nodes when `path()` or `re_path()` maps a URL pattern to a view function or class. These edges represent the HTTP routing chain.
**Signal wiring** — When `signals.py` uses `post_save.connect(handler, sender=Model)` or `@receiver(post_save, sender=Model)`, create `subscribes` edges from the signal handler function to the model class. Create `publishes` edges from the model to the signal handler to show the trigger direction.
**ORM relationships** — When `models.py` defines `ForeignKey`, `OneToOneField`, or `ManyToManyField`, create `depends_on` edges between the model classes with a description indicating the relationship type and cardinality.
**Serializer-to-model binding** — When a DRF serializer has `model = MyModel` in its `Meta` class, create a `depends_on` edge from the serializer to the model.
**View-to-serializer binding** — When a DRF ViewSet or APIView references a serializer class, create a `depends_on` edge from the view to the serializer.
### Architectural Layers for Django
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:api` | API Layer | `views.py`, `serializers.py`, `urls.py`, DRF ViewSets and APIViews |
| `layer:data` | Data Layer | `models.py`, `migrations/`, database utility files |
| `layer:service` | Service Layer | `signals.py`, `tasks.py`, custom managers, service modules |
| `layer:ui` | UI Layer | `templates/`, `forms.py`, `templatetags/` |
| `layer:middleware` | Middleware Layer | `middleware.py`, `permissions.py`, authentication backends |
| `layer:config` | Config Layer | `settings.py`, `urls.py` (root), `wsgi.py`, `asgi.py`, `apps.py`, `manage.py` |
| `layer:test` | Test Layer | `tests.py`, `tests/` directory, `conftest.py` |
### Notable Patterns to Capture in languageLesson
- **Fat models vs. thin views**: Django encourages business logic in model methods, keeping views thin HTTP adapters
- **Django ORM lazy evaluation**: QuerySets are not evaluated until iterated — chain filters without DB hits
- **Class-based views (CBVs)**: Mixins like `LoginRequiredMixin`, `PermissionRequiredMixin` compose behavior through multiple inheritance
- **Signal anti-patterns**: Signals create invisible coupling; a signal in `signals.py` may be triggered by a `save()` call anywhere in the codebase
- **App isolation**: Each Django app (`INSTALLED_APPS`) should be self-contained with its own models, views, urls, and migrations

57
.qoder/skills/understand/frameworks/express.md Normal file
View File

@@ -0,0 +1,57 @@
# Express Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Express is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Express Project Structure
When analyzing an Express project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `app.js`, `app.ts` | Application entry point — creates Express app, mounts middleware and routes | `entry-point`, `config` |
| `server.js`, `server.ts`, `index.js`, `index.ts` | Server bootstrap — starts HTTP listener, may import app | `entry-point`, `config` |
| `routes/*.js`, `routes/*.ts` | Route definitions — map HTTP methods and paths to handlers | `api-handler`, `routing` |
| `controllers/*.js`, `controllers/*.ts` | Request handlers — process requests, orchestrate services, return responses | `api-handler`, `service` |
| `models/*.js`, `models/*.ts` | Data models — Mongoose schemas, Sequelize models, or plain data definitions | `data-model` |
| `middleware/*.js`, `middleware/*.ts` | Middleware functions — authentication, logging, validation, error handling | `middleware` |
| `services/*.js`, `services/*.ts` | Business logic — domain operations decoupled from HTTP layer | `service` |
| `db/*.js`, `db/*.ts`, `database/*.js` | Database connection and configuration | `data-model`, `config` |
| `config/*.js`, `config/*.ts` | Application configuration — environment variables, feature flags | `config` |
| `validators/*.js`, `validators/*.ts` | Request validation schemas (Joi, Zod, express-validator) | `validation`, `utility` |
| `utils/*.js`, `utils/*.ts` | Shared utility functions | `utility` |
| `tests/*.js`, `test/*.js`, `__tests__/*.js` | Unit and integration tests | `test` |
### Edge Patterns to Look For
**Route mounting** — When `app.use('/api/users', usersRouter)` mounts a router, create `depends_on` edges from the main app to the router module. These edges represent the HTTP routing tree.
**Middleware chain** — When `app.use(cors())`, `app.use(authMiddleware)`, or `router.use(validate)` registers middleware, create middleware edges from the app or router to the middleware function. Order matters — middleware executes in registration order.
**Controller-to-service calls** — When a controller imports and calls a service function, create `depends_on` edges from the controller to the service. This represents the separation between HTTP handling and business logic.
**Model relationships** — When models reference each other (Mongoose `ref`, Sequelize associations), create `depends_on` edges between model files with descriptions indicating the relationship type.
### Architectural Layers for Express
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:api` | API Layer | `routes/`, `controllers/`, request validators |
| `layer:data` | Data Layer | `models/`, `db/`, migration files, seeders |
| `layer:service` | Service Layer | `services/`, business logic modules |
| `layer:middleware` | Middleware Layer | `middleware/`, error handlers, authentication, logging |
| `layer:config` | Config Layer | `app.js`, `config/`, environment setup, `server.js` |
| `layer:utility` | Utility Layer | `utils/`, `helpers/`, shared pure functions |
| `layer:test` | Test Layer | `tests/`, `__tests__/`, `*.test.js`, `*.spec.js` |
### Notable Patterns to Capture in languageLesson
- **Middleware chain (req, res, next)**: Express processes requests through a pipeline of middleware functions — each receives the request, response, and a `next()` callback to pass control forward
- **Error-handling middleware (4 params)**: Middleware with signature `(err, req, res, next)` catches errors — must be registered after all routes to act as a global error handler
- **Router modularity**: `express.Router()` creates modular, mountable route handlers that can be composed into the main app at different path prefixes
- **MVC pattern**: Express apps commonly separate concerns into Models (data), Views (response formatting), and Controllers (request handling)
- **Body parsing and validation**: Request body parsing (`express.json()`, `express.urlencoded()`) and validation (Joi, Zod, express-validator) are middleware concerns applied before route handlers

58
.qoder/skills/understand/frameworks/fastapi.md Normal file
View File

@@ -0,0 +1,58 @@
# FastAPI Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when FastAPI is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## FastAPI Project Structure
When analyzing a FastAPI project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `main.py`, `app.py` | Application factory — creates and configures the `FastAPI()` instance | `entry-point`, `config` |
| `*/routers/*.py`, `*/api/*.py` | `APIRouter` modules — group related endpoints by domain | `api-handler`, `routing` |
| `*/schemas.py`, `*/schemas/*.py` | Pydantic request/response models | `type-definition`, `serialization` |
| `*/models.py`, `*/models/*.py` | SQLAlchemy ORM models or other DB models | `data-model` |
| `*/dependencies.py`, `*/deps.py` | `Depends()` provider functions — shared logic injected into routes | `service`, `middleware` |
| `*/crud.py`, `*/repository.py` | Database access layer — CRUD operations | `data-model`, `service` |
| `*/database.py`, `*/db.py` | DB engine, session factory, connection management | `config`, `data-model` |
| `*/config.py`, `*/settings.py` | `pydantic-settings` / `BaseSettings` config classes | `config` |
| `*/middleware.py` | Starlette middleware classes | `middleware` |
| `*/exceptions.py` | Custom exception classes and exception handlers | `utility` |
| `*/security.py`, `*/auth.py` | Auth utilities — JWT decoding, password hashing, OAuth helpers | `service`, `middleware` |
| `*/tasks.py` | Background tasks or Celery task definitions | `service`, `event-handler` |
| `*/tests/*.py`, `test_*.py` | pytest test files | `test` |
| `conftest.py` | pytest fixtures and test configuration | `test`, `config` |
### Edge Patterns to Look For
**Router inclusion chain** — When `app.include_router(some_router, prefix="/api")` appears in `main.py` or a router aggregator, create `imports` + `depends_on` edges from the main app file to each router module. This builds the URL hierarchy graph.
**Dependency injection tree** — When a route function or another `Depends()` provider imports and calls `Depends(some_function)`, create `depends_on` edges from the caller to the dependency provider. Trace these chains — they often span multiple files (e.g., route → auth dependency → DB session dependency).
**Pydantic model inheritance** — When a schema class inherits from another (e.g., `class UserCreate(UserBase)`), create `inherits` edges between the schema class nodes.
**ORM model relationships** — When SQLAlchemy models use `relationship()`, `ForeignKey`, create `depends_on` edges between the model classes.
**CRUD-to-model binding** — When a `crud.py` function takes a model type as an argument or directly references a model class, create `depends_on` edges from the CRUD file to the model file.
### Architectural Layers for FastAPI
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:api` | API Layer | Router files, endpoint functions with `@router.get/post/...` decorators |
| `layer:types` | Types Layer | Pydantic schema files, request/response models |
| `layer:service` | Service Layer | `dependencies.py`, `crud.py`, business logic modules |
| `layer:data` | Data Layer | ORM models, `database.py`, migrations |
| `layer:config` | Config Layer | `main.py` / `app.py` factory, `settings.py`, `config.py` |
| `layer:middleware` | Middleware Layer | `middleware.py`, `security.py`, `auth.py`, exception handlers |
| `layer:test` | Test Layer | `tests/`, `conftest.py` |
### Notable Patterns to Capture in languageLesson
- **Dependency injection as composition**: FastAPI's `Depends()` is a first-class DI system — a route can declare any number of dependencies, each of which can have their own dependencies, forming a tree resolved at request time
- **Pydantic for validation**: Request bodies, query params, and path params are automatically validated by Pydantic — invalid input raises `422 Unprocessable Entity` before your code runs
- **Async endpoints**: `async def` routes run in the event loop; `def` routes run in a threadpool — mixing them incorrectly can cause performance issues
- **Path operation order**: FastAPI matches routes in declaration order; a catch-all route before a specific one will shadow it

53
.qoder/skills/understand/frameworks/flask.md Normal file
View File

@@ -0,0 +1,53 @@
# Flask Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Flask is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Flask Project Structure
When analyzing a Flask project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `app.py`, `__init__.py` (in app package) | Application factory (`create_app()`) or direct `Flask(__name__)` instance | `entry-point`, `config` |
| `run.py`, `wsgi.py` | Production/dev server entry point | `entry-point`, `config` |
| `*/views.py`, `*/routes.py` | Route handler functions with `@app.route` or `@blueprint.route` | `api-handler`, `routing` |
| `*/blueprints/*.py`, `*/api/*.py` | Blueprint modules — group routes by feature | `api-handler`, `routing` |
| `*/models.py` | SQLAlchemy models or other ORM models | `data-model` |
| `*/forms.py` | WTForms form classes | `validation`, `ui` |
| `*/schemas.py` | Marshmallow serialization schemas | `serialization`, `type-definition` |
| `*/config.py` | Config classes (`DevelopmentConfig`, `ProductionConfig`) | `config` |
| `*/extensions.py` | Flask extension initialization (`db = SQLAlchemy()`, `login_manager = LoginManager()`) | `config`, `singleton` |
| `*/decorators.py` | Custom route decorators (auth guards, rate limiting) | `middleware`, `utility` |
| `*/utils.py`, `*/helpers.py` | Shared utility functions | `utility` |
| `*/templates/**/*.html` | Jinja2 templates | `ui` |
| `*/static/` | CSS, JS, and asset files | `assets` |
| `*/tests/*.py`, `test_*.py` | pytest or unittest test files | `test` |
### Edge Patterns to Look For
**Blueprint registration** — When `app.register_blueprint(bp, url_prefix='/api')` appears in the application factory, create `depends_on` edges from the app factory to each blueprint module.
**Extension coupling** — When a view imports from `extensions.py` (e.g., `from .extensions import db, login_manager`), create `imports` edges to show which views depend on which extensions.
**Before/after request hooks** — When `@app.before_request` or `@blueprint.before_request` decorates a function, create `middleware` edges from those functions to the app/blueprint they attach to.
### Architectural Layers for Flask
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:api` | API Layer | Blueprint route files, view functions |
| `layer:data` | Data Layer | `models.py`, database migration files |
| `layer:service` | Service Layer | Business logic modules, `schemas.py`, service classes |
| `layer:ui` | UI Layer | `templates/`, `forms.py`, `static/` |
| `layer:config` | Config Layer | `app.py` factory, `config.py`, `extensions.py` |
| `layer:middleware` | Middleware Layer | `decorators.py`, before/after request hooks |
| `layer:test` | Test Layer | Test files, `conftest.py` |
### Notable Patterns to Capture in languageLesson
- **Application factory pattern**: `create_app()` functions allow multiple app instances (e.g., for testing) and delay extension initialization — avoids circular imports
- **Blueprint modularity**: Blueprints group related routes, templates, and static files; they are registered on the app with a URL prefix, making them independently testable
- **Flask extension protocol**: Extensions follow `init_app(app)` for lazy initialization — the extension object is created globally but bound to an app instance later

59
.qoder/skills/understand/frameworks/gin.md Normal file
View File

@@ -0,0 +1,59 @@
# Gin (Go) Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Gin is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Gin Project Structure
When analyzing a Gin project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `main.go` | Application entry point — initializes the Gin engine, registers routes, starts the server | `entry-point`, `config` |
| `cmd/*.go`, `cmd/**/*.go` | CLI entry points — multiple binaries in a multi-command project | `entry-point`, `config` |
| `handlers/*.go`, `handler/*.go` | HTTP handlers — process requests with `gin.Context` | `api-handler` |
| `controllers/*.go`, `controller/*.go` | Controllers — alternative naming for HTTP handlers | `api-handler` |
| `routes/*.go`, `router/*.go` | Route definitions — register endpoints and route groups | `routing`, `config` |
| `models/*.go`, `model/*.go` | Data models — struct definitions mapped to database tables | `data-model` |
| `middleware/*.go` | Middleware functions — authentication, logging, CORS, rate limiting | `middleware` |
| `services/*.go`, `service/*.go` | Business logic — domain operations decoupled from HTTP layer | `service` |
| `repository/*.go`, `repo/*.go` | Data access layer — database queries and persistence logic | `data-model`, `service` |
| `config/*.go`, `config.go` | Application configuration — environment loading, struct-based config | `config` |
| `dto/*.go` | Data transfer objects — request and response structs | `type-definition` |
| `utils/*.go`, `pkg/*.go` | Shared utility packages | `utility` |
| `*_test.go` | Unit and integration tests | `test` |
### Edge Patterns to Look For
**Route group registration** — When `r.Group("/api")` creates a route group and registers handlers, create `configures` edges from the route definition file to each handler. Route groups organize endpoints by prefix and shared middleware.
**Handler-to-service calls** — When a handler function calls a service method, create `depends_on` edges from the handler to the service. This represents the separation between HTTP handling and business logic.
**Service-to-repository calls** — When a service calls a repository method for data access, create `depends_on` edges from the service to the repository. This represents the data access abstraction.
**Middleware chaining** — When `r.Use(middleware)` or a route group applies middleware, create middleware edges from the router or group to the middleware function. Middleware executes in registration order.
### Architectural Layers for Gin
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:api` | API Layer | `handlers/`, `controllers/`, HTTP handler functions |
| `layer:data` | Data Layer | `models/`, `repository/`, database access, migrations |
| `layer:service` | Service Layer | `services/`, business logic |
| `layer:middleware` | Middleware Layer | `middleware/`, authentication, logging, rate limiting |
| `layer:config` | Config Layer | `main.go`, `routes/`, `config/`, environment setup |
| `layer:utility` | Utility Layer | `utils/`, `pkg/`, shared helper packages |
| `layer:test` | Test Layer | `*_test.go`, test fixtures, test helpers |
### Notable Patterns to Capture in languageLesson
- **Handler functions with gin.Context**: Every Gin handler receives a `*gin.Context` parameter — it provides request parsing (`c.Bind`, `c.Param`, `c.Query`), response writing (`c.JSON`, `c.HTML`), and control flow (`c.Abort`, `c.Next`)
- **Middleware chain with c.Next()**: Middleware calls `c.Next()` to pass control to the next handler in the chain — code before `c.Next()` runs pre-handler, code after runs post-handler
- **Route grouping for modular APIs**: `r.Group("/v1")` creates modular sub-routers that can have their own middleware stack — enables versioning and access control at the group level
- **Dependency injection via constructors (no framework DI)**: Go has no DI framework — dependencies are passed as constructor parameters (e.g., `NewUserHandler(userService)`) and stored as struct fields
- **Interface-driven design for testability**: Services and repositories are defined as interfaces — handlers depend on the interface, enabling mock implementations in tests
- **Error handling with gin.Error**: Gin collects errors via `c.Error(err)` — middleware can inspect `c.Errors` after handler execution to implement centralized error logging and response formatting

59
.qoder/skills/understand/frameworks/nextjs.md Normal file
View File

@@ -0,0 +1,59 @@
# Next.js Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Next.js is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Next.js Project Structure
When analyzing a Next.js project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `app/layout.tsx` | Root layout — wraps all pages, defines HTML shell and global providers | `entry-point`, `config`, `ui` |
| `app/page.tsx` | Root page component — renders at `/` | `ui`, `routing` |
| `app/**/page.tsx` | Route page components — file path determines URL | `ui`, `routing` |
| `app/**/layout.tsx` | Nested layouts — wrap child routes with shared UI | `ui`, `config` |
| `app/**/loading.tsx` | Loading UI — shown as Suspense fallback during route transitions | `ui` |
| `app/**/error.tsx` | Error boundary — catches errors in the route segment | `ui` |
| `app/**/not-found.tsx` | 404 UI — shown when `notFound()` is called | `ui` |
| `app/api/**/route.ts` | API route handlers — serverless endpoint functions (GET, POST, etc.) | `api-handler` |
| `middleware.ts` | Edge middleware — intercepts requests before they reach routes | `middleware` |
| `lib/*.ts`, `lib/**/*.ts` | Shared server-side utilities, data access, and business logic | `service` |
| `components/*.tsx`, `components/**/*.tsx` | Reusable UI components | `ui` |
| `next.config.js`, `next.config.mjs`, `next.config.ts` | Next.js configuration — redirects, rewrites, env, webpack overrides | `config` |
| `actions/*.ts`, `app/**/actions.ts` | Server Actions — server-side mutation functions callable from client | `service`, `api-handler` |
### Edge Patterns to Look For
**Layout nesting** — When `app/foo/layout.tsx` wraps `app/foo/page.tsx` and `app/foo/bar/page.tsx`, create `contains` edges from the layout to the pages it wraps. Layouts compose via the file-system hierarchy.
**API route handlers** — When a `route.ts` file exports named functions (GET, POST, PUT, DELETE), create edges from consuming components or server actions to the route handler based on fetch calls.
**Server/Client component boundary** — Files with `"use client"` directive at the top are Client Components. All other components in the `app/` directory are Server Components by default. Create `depends_on` edges that cross this boundary and note the boundary in the edge description.
**Parallel routes** — When `app/@slot/page.tsx` patterns appear, create `contains` edges from the parent layout to each parallel slot. These render simultaneously in the same layout.
**Route groups** — Directories wrapped in parentheses `(group)` organize routes without affecting the URL path. Note these in node descriptions.
### Architectural Layers for Next.js
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:ui` | UI Layer | `app/**/page.tsx`, `app/**/layout.tsx`, `components/`, loading/error boundaries |
| `layer:api` | API Layer | `app/api/**/route.ts`, API route handlers |
| `layer:service` | Service Layer | `lib/`, server actions, data-fetching utilities |
| `layer:middleware` | Middleware Layer | `middleware.ts`, edge functions |
| `layer:config` | Config Layer | `next.config.*`, root layout, `tailwind.config.*`, environment setup |
| `layer:test` | Test Layer | `__tests__/`, `*.test.tsx`, `*.spec.tsx`, `e2e/` |
### Notable Patterns to Capture in languageLesson
- **Server Components by default**: Components in the `app/` directory are Server Components — no JavaScript is sent to the client unless `"use client"` is declared
- **Server Actions for mutations**: Functions marked with `"use server"` can be called directly from client components, replacing traditional API routes for form submissions and mutations
- **App Router file conventions**: Special files (`page`, `layout`, `loading`, `error`, `not-found`, `route`) define behavior by naming convention within the file-system router
- **ISR and static generation**: `generateStaticParams` pre-renders pages at build time; revalidation strategies control cache freshness
- **Parallel and intercepting routes**: `@slot` directories enable parallel rendering; `(.)` prefix directories enable route interception for modal patterns

65
.qoder/skills/understand/frameworks/rails.md Normal file
View File

@@ -0,0 +1,65 @@
# Ruby on Rails Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Rails is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Rails Project Structure
When analyzing a Ruby on Rails project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `config.ru` | Rack entry point — boots the Rails application for the web server | `entry-point` |
| `config/application.rb` | Application configuration — sets up Rails, loads gems, configures middleware | `entry-point`, `config` |
| `app/controllers/*_controller.rb` | Controllers — handle HTTP requests, orchestrate models, render responses | `api-handler` |
| `app/controllers/concerns/*.rb` | Controller concerns — shared controller behavior via mixins | `middleware`, `utility` |
| `app/models/*.rb` | ActiveRecord models — map to database tables, contain validations and associations | `data-model` |
| `app/models/concerns/*.rb` | Model concerns — shared model behavior via mixins | `utility` |
| `app/views/**/*.erb`, `app/views/**/*.haml` | View templates — HTML rendering with embedded Ruby | `ui` |
| `app/helpers/*_helper.rb` | View helpers — utility methods available in templates | `utility` |
| `app/mailers/*_mailer.rb` | Action Mailer classes — send email notifications | `service` |
| `app/jobs/*_job.rb` | Active Job classes — background job processing | `service` |
| `app/channels/*_channel.rb` | Action Cable channels — WebSocket communication | `service` |
| `app/serializers/*_serializer.rb` | API serializers — JSON response formatting (ActiveModelSerializers, Blueprinter) | `api-handler`, `utility` |
| `app/services/*.rb` | Service objects — encapsulate complex business logic | `service` |
| `db/migrate/*.rb` | Database migrations — schema changes versioned by timestamp | `config`, `data-model` |
| `db/schema.rb`, `db/structure.sql` | Generated schema snapshot — current database structure | `data-model`, `config` |
| `config/routes.rb` | Route definitions — maps URLs to controller actions | `routing`, `config` |
| `config/initializers/*.rb` | Initializers — run once at boot to configure gems and services | `config` |
| `lib/**/*.rb` | Library code — custom classes, Rake tasks, extensions | `utility`, `service` |
| `spec/**/*_spec.rb`, `test/**/*_test.rb` | RSpec or Minitest test files | `test` |
### Edge Patterns to Look For
**Route-to-controller mapping** — When `config/routes.rb` defines `resources :users` or `get '/foo', to: 'bar#baz'`, create `configures` edges from the routes file to the corresponding controller. RESTful resources generate a full set of action mappings.
**ActiveRecord associations** — When models define `has_many`, `belongs_to`, `has_one`, or `has_and_belongs_to_many`, create `depends_on` edges between model files with descriptions indicating the association type and direction.
**Controller-to-model** — When a controller calls model methods (`User.find`, `@post.save`), create `depends_on` edges from the controller to the model. Controllers are the primary consumers of model data.
**Callbacks** — When models or controllers use `before_action`, `after_save`, `before_validation`, or similar callbacks, note these as middleware-like edges. Callbacks create implicit execution paths that are not visible from the call site.
### Architectural Layers for Rails
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:api` | API Layer | `app/controllers/`, `app/serializers/`, API-specific controllers |
| `layer:data` | Data Layer | `app/models/`, `db/migrate/`, `db/schema.rb` |
| `layer:ui` | UI Layer | `app/views/`, `app/helpers/`, `app/assets/`, `app/javascript/` |
| `layer:service` | Service Layer | `app/mailers/`, `app/jobs/`, `app/channels/`, `app/services/`, `lib/` |
| `layer:config` | Config Layer | `config/routes.rb`, `config/initializers/`, `config/application.rb`, `config.ru` |
| `layer:middleware` | Middleware Layer | `app/middleware/`, controller concerns, Rack middleware |
| `layer:test` | Test Layer | `spec/`, `test/`, `*.spec.rb`, `*_test.rb` |
### Notable Patterns to Capture in languageLesson
- **Convention over configuration**: Rails derives routing, table names, and file locations from naming conventions — `UsersController` maps to `users_controller.rb`, handles `/users`, and queries the `users` table
- **ActiveRecord pattern**: Models are database wrappers — each model class maps to a table, instances map to rows, and attributes map to columns with automatic type coercion
- **Concerns for shared behavior**: `ActiveSupport::Concern` modules are mixins included in models or controllers to share validations, scopes, callbacks, and methods across classes
- **Strong parameters for mass-assignment protection**: `params.require(:user).permit(:name, :email)` whitelists attributes — controllers must explicitly declare which fields can be set from user input
- **RESTful resource routing**: `resources :posts` generates seven standard CRUD routes — Rails strongly encourages RESTful design where each controller maps to a resource
- **Callbacks and observers**: `before_save`, `after_create`, and similar callbacks inject logic into the object lifecycle — they create invisible execution paths that can be difficult to trace

55
.qoder/skills/understand/frameworks/react.md Normal file
View File

@@ -0,0 +1,55 @@
# React Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when React is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## React Project Structure
When analyzing a React project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `src/App.tsx` | Root application component — mounts providers, router, and top-level layout | `entry-point`, `ui` |
| `components/*.tsx`, `components/**/*.tsx` | Reusable UI components | `ui` |
| `hooks/*.ts`, `hooks/*.tsx` | Custom React hooks — encapsulate reusable stateful logic | `service`, `utility` |
| `contexts/*.tsx`, `context/*.tsx` | React Context providers and consumers — shared state across component tree | `service`, `state` |
| `pages/*.tsx`, `views/*.tsx` | Page-level components mapped to routes | `ui`, `routing` |
| `utils/*.ts`, `helpers/*.ts` | Pure utility functions — formatting, validation, transformations | `utility` |
| `types/*.ts`, `types/*.d.ts` | TypeScript type definitions and interfaces | `type-definition` |
| `services/*.ts`, `api/*.ts` | API client functions and data-fetching logic | `service` |
| `store/*.ts`, `slices/*.ts` | State management (Redux, Zustand, etc.) | `service`, `state` |
| `constants/*.ts` | Application-wide constants and enums | `config` |
| `__tests__/*.tsx`, `*.test.tsx`, `*.spec.tsx` | Unit and integration tests | `test` |
### Edge Patterns to Look For
**Component composition** — When a parent component renders a child component in its JSX return, create `contains` edges from the parent to the child. These edges represent the component tree hierarchy.
**Hook usage** — When a component or hook imports and calls a custom hook (`useX`), create `depends_on` edges from the consumer to the hook module. Hooks are the primary mechanism for shared logic in React.
**Context provider/consumer** — When a Context provider wraps components, create `publishes` edges from the provider to the context definition. When components call `useContext` or use a custom context hook, create `subscribes` edges from the consumer to the context.
**Props drilling chains** — When props are passed through multiple component layers without being used, create `depends_on` edges along the chain to surface the coupling depth.
### Architectural Layers for React
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:ui` | UI Layer | `components/`, `pages/`, `views/`, layout components |
| `layer:service` | Service Layer | `hooks/`, `contexts/`, `services/`, `api/`, `store/` |
| `layer:types` | Types Layer | `types/`, shared TypeScript interfaces and type definitions |
| `layer:utility` | Utility Layer | `utils/`, `helpers/`, pure functions |
| `layer:config` | Config Layer | `App.tsx`, router configuration, provider setup, constants |
| `layer:test` | Test Layer | `__tests__/`, `*.test.tsx`, `*.spec.tsx` |
### Notable Patterns to Capture in languageLesson
- **Component composition over inheritance**: React favors composing components via props and children rather than class inheritance hierarchies
- **Custom hooks for reusable logic**: Hooks prefixed with `use` extract stateful logic into shareable modules without changing the component tree
- **React.memo for performance**: Components wrapped in `React.memo` skip re-renders when props are unchanged — indicates performance-sensitive paths
- **Controlled vs. uncontrolled components**: Controlled components derive state from props; uncontrolled components manage internal state via refs
- **Render props pattern**: Components that accept a function as children or a render prop to delegate rendering decisions to the consumer

59
.qoder/skills/understand/frameworks/spring.md Normal file
View File

@@ -0,0 +1,59 @@
# Spring Boot Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Spring Boot is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Spring Boot Project Structure
When analyzing a Spring Boot project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `*Application.java`, `*Application.kt` | Application entry point — `@SpringBootApplication` class with `main()` method | `entry-point`, `config` |
| `*Controller.java`, `*RestController.java` | REST controllers — handle HTTP requests, delegate to services | `api-handler` |
| `*Service.java` | Service interfaces — define business operation contracts | `service` |
| `*ServiceImpl.java` | Service implementations — contain business logic | `service` |
| `*Repository.java` | Spring Data repositories — data access interfaces extending JpaRepository/CrudRepository | `data-model` |
| `*Entity.java` | JPA entities — map to database tables via `@Entity` annotation | `data-model` |
| `*DTO.java`, `*Request.java`, `*Response.java` | Data transfer objects — request/response payloads | `type-definition` |
| `*Config.java`, `*Configuration.java` | Configuration classes — `@Configuration` beans, security config, web config | `config` |
| `*Filter.java` | Servlet filters — intercept requests before they reach controllers | `middleware` |
| `*Interceptor.java` | Handler interceptors — pre/post processing around controller methods | `middleware` |
| `*Advice.java`, `*ExceptionHandler.java` | Controller advice — global exception handling and response wrapping | `middleware` |
| `*Mapper.java` | Object mappers — convert between entities and DTOs (MapStruct, ModelMapper) | `utility` |
| `application.yml`, `application.properties` | Application configuration — profiles, datasource, server settings | `config` |
| `*Test.java`, `*Tests.java`, `*IT.java` | Unit tests, integration tests | `test` |
### Edge Patterns to Look For
**@Autowired injection** — When a class injects a dependency via `@Autowired`, constructor injection, or `@Inject`, create `depends_on` edges from the consumer to the injected bean. Constructor injection is preferred and most common in modern Spring.
**Controller-Service-Repository chain** — The canonical call chain is `@RestController` -> `@Service` -> `@Repository`. Create `depends_on` edges along this chain to show the layered architecture.
**@Entity relationships** — When entities define `@OneToMany`, `@ManyToOne`, `@OneToOne`, or `@ManyToMany` annotations, create `depends_on` edges between entity classes with descriptions indicating the relationship type and direction.
**@Configuration bean definitions** — When a `@Configuration` class defines `@Bean` methods, create `configures` edges from the configuration class to the types it produces. These beans become available for injection throughout the application.
### Architectural Layers for Spring Boot
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:api` | API Layer | `*Controller.java`, REST endpoints, API documentation |
| `layer:service` | Service Layer | `*Service.java`, `*ServiceImpl.java`, business logic |
| `layer:data` | Data Layer | `*Repository.java`, `*Entity.java`, JPA mappings, database migrations |
| `layer:types` | Types Layer | `*DTO.java`, `*Request.java`, `*Response.java`, shared value objects |
| `layer:config` | Config Layer | `*Configuration.java`, `application.yml`, security config, `*Application.java` |
| `layer:middleware` | Middleware Layer | `*Filter.java`, `*Interceptor.java`, `*Advice.java`, security filters |
| `layer:test` | Test Layer | `*Test.java`, `*Tests.java`, `*IT.java`, test configuration |
### Notable Patterns to Capture in languageLesson
- **Dependency injection via constructor injection**: Spring favors constructor injection over field injection (`@Autowired` on fields) — it makes dependencies explicit, supports immutability, and simplifies testing
- **Layered architecture (Controller -> Service -> Repository)**: Spring Boot applications follow a strict layered pattern where controllers handle HTTP, services contain business logic, and repositories manage persistence
- **Spring Security filter chain**: Security is implemented as a chain of servlet filters — `SecurityFilterChain` beans configure authentication, authorization, CORS, and CSRF protection
- **JPA entity lifecycle**: Entities transition through states (transient, managed, detached, removed) — understanding this lifecycle is essential for tracing data flow through the persistence layer
- **AOP for cross-cutting concerns**: `@Aspect` classes with `@Before`, `@After`, and `@Around` advice inject behavior at join points — used for logging, transactions (`@Transactional`), and caching (`@Cacheable`)

59
.qoder/skills/understand/frameworks/vue.md Normal file
View File

@@ -0,0 +1,59 @@
# Vue Framework Addendum
> Injected into file-analyzer and architecture-analyzer prompts when Vue is detected.
> Do NOT use as a standalone prompt — always appended to the base prompt template.
## Vue Project Structure
When analyzing a Vue project, apply these additional conventions on top of the base analysis rules.
### Canonical File Roles
| File / Pattern | Role | Tags |
|---|---|---|
| `src/App.vue` | Root application component — mounts the top-level layout and router view | `entry-point`, `ui` |
| `src/main.ts`, `src/main.js` | Application bootstrap — creates Vue app instance, registers plugins, mounts to DOM | `entry-point`, `config` |
| `components/*.vue`, `components/**/*.vue` | Reusable UI components | `ui` |
| `views/*.vue`, `pages/*.vue` | Page-level components mapped to routes | `ui`, `routing` |
| `composables/*.ts`, `composables/*.js` | Composable functions — reusable stateful logic using Composition API | `service`, `utility` |
| `store/*.ts`, `stores/*.ts` | State management modules (Pinia stores or Vuex modules) | `service`, `state` |
| `router/*.ts`, `router/index.ts` | Vue Router configuration — route definitions, navigation guards | `config`, `routing` |
| `plugins/*.ts`, `plugins/*.js` | Vue plugin registrations — extend app functionality (i18n, auth, etc.) | `config` |
| `utils/*.ts`, `helpers/*.ts` | Pure utility functions | `utility` |
| `types/*.ts`, `types/*.d.ts` | TypeScript type definitions and interfaces | `type-definition` |
| `api/*.ts`, `services/*.ts` | API client functions and data-fetching logic | `service` |
| `directives/*.ts` | Custom Vue directives | `utility` |
| `tests/*.spec.ts`, `__tests__/*.spec.ts` | Unit and integration tests | `test` |
### Edge Patterns to Look For
**Component parent-child** — When a parent component uses a child component in its `<template>`, create `contains` edges from the parent to the child. Template refs and slot usage further indicate composition relationships.
**Composable usage** — When a component or composable imports and calls a `useX` function, create `depends_on` edges from the consumer to the composable module. Composables are the primary mechanism for shared stateful logic.
**Store actions/getters** — When components or composables import and use a Pinia store (`useXStore()`), create `depends_on` edges from the consumer to the store. Store-to-store dependencies should also be captured.
**Router view mapping** — When `router/index.ts` maps paths to view components, create `configures` edges from the router to each view component. Navigation guards add middleware-like edges.
**Plugin registration** — When `main.ts` calls `app.use(plugin)`, create `configures` edges from the bootstrap file to each plugin.
### Architectural Layers for Vue
Assign nodes to these layers when detected:
| Layer ID | Layer Name | What Goes Here |
|---|---|---|
| `layer:ui` | UI Layer | `components/`, `views/`, `pages/`, layout components |
| `layer:service` | Service Layer | `composables/`, `store/`, `stores/`, `api/`, `services/` |
| `layer:config` | Config Layer | `router/`, `plugins/`, `main.ts`, `App.vue`, configuration files |
| `layer:utility` | Utility Layer | `utils/`, `helpers/`, `directives/`, pure functions |
| `layer:test` | Test Layer | `tests/`, `__tests__/`, `*.spec.ts` |
### Notable Patterns to Capture in languageLesson
- **Composition API over Options API**: Modern Vue favors `setup()` and `<script setup>` with composables, replacing the Options API's data/methods/computed separation
- **Pinia for state management**: Pinia stores provide type-safe, modular state with actions and getters — each store is independently defined and can depend on other stores
- **Vue Router with navigation guards**: `beforeEach`, `beforeEnter`, and `afterEach` guards act as middleware for route transitions — used for authentication and data prefetching
- **Single-file components (.vue)**: Each `.vue` file encapsulates template, script, and style in a single file — the `<script setup>` syntax is the recommended concise form
- **Reactive refs and computed properties**: `ref()` and `reactive()` create reactive state; `computed()` derives values that auto-update — understanding reactivity is key to tracing data flow
- **Provide/inject for deep dependency passing**: `provide()` and `inject()` pass values down the component tree without prop drilling — creates implicit dependencies that should be captured as edges