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

This commit is contained in:
2026-06-18 21:29:41 +08:00
parent 3d977d0a2d
commit 8afeb2e4d9
160 changed files with 21893 additions and 0 deletions

View File

@@ -0,0 +1,47 @@
# C++ Language Prompt Snippet
## Key Concepts
- **Templates**: Function, class, and variadic templates for generic compile-time polymorphism
- **RAII**: Resource Acquisition Is Initialization — tie resource lifetime to object scope
- **Smart Pointers**: `unique_ptr` (exclusive), `shared_ptr` (reference-counted), `weak_ptr` (non-owning)
- **Move Semantics**: Rvalue references (`&&`) and `std::move` for efficient resource transfer
- **Operator Overloading**: Define custom behavior for operators on user-defined types
- **Virtual Functions and Vtable**: Runtime polymorphism through virtual method dispatch tables
- **Namespaces**: Organize symbols and prevent name collisions across translation units
- **Constexpr**: Compile-time evaluation of functions and variables for zero-runtime-cost computation
- **Lambda Expressions**: Anonymous functions with capture lists for closures
- **STL Containers and Algorithms**: Standard containers (vector, map, set) and generic algorithms
- **Concepts (C++20)**: Named constraints on template parameters replacing SFINAE patterns
## Import Patterns
- `#include <system_header>` — include standard library or system headers
- `#include "local_header.h"` — include project-local header files
- `using namespace std` — bring all names from std into scope (avoid in headers)
- `using std::vector` — selectively bring specific names into scope
## File Patterns
- `.h` / `.hpp` — header files containing declarations, templates, and inline definitions
- `.cpp` / `.cc` — implementation files with function definitions and static data
- `CMakeLists.txt` — CMake build system configuration
- `Makefile` — Make-based build rules and targets
- `main.cpp` — program entry point containing `int main()`
## Common Frameworks
- **Qt** — Cross-platform application framework with signal/slot mechanism
- **Boost** — Extensive collection of peer-reviewed portable libraries
- **Catch2** — Header-only testing framework with BDD-style syntax
- **Google Test** — Testing framework with fixtures, assertions, and mocking
- **gRPC** — High-performance RPC framework for service communication
## Example Language Notes
> Uses `std::unique_ptr<T>` for RAII-based ownership, ensuring deterministic cleanup
> when scope exits. The unique pointer cannot be copied, only moved, making ownership
> transfer explicit and preventing accidental double-free errors.
>
> Header/implementation separation (`.h`/`.cpp`) controls compilation boundaries —
> changes to a `.cpp` file only recompile that translation unit, not all includers.

View File

@@ -0,0 +1,46 @@
# C# Language Prompt Snippet
## Key Concepts
- **LINQ Queries**: Language-integrated queries using method syntax (`.Where().Select()`) or query syntax
- **Async/Await with Task**: Asynchronous programming model returning `Task<T>` for non-blocking I/O
- **Generics and Constraints**: Type parameters with `where T : class, IDisposable` constraint clauses
- **Properties (get/set)**: First-class property syntax with backing fields, auto-properties, and init-only
- **Delegates and Events**: Type-safe function pointers; events provide publisher-subscriber pattern
- **Attributes**: Metadata annotations (`[HttpGet]`, `[Authorize]`) for declarative configuration
- **Nullable Reference Types**: Compiler-enforced null safety with `?` annotations (C# 8+)
- **Pattern Matching**: `is`, `switch` expressions with type, property, and relational patterns
- **Records and Init-Only Setters**: Immutable reference types with value equality semantics (C# 9+)
- **Dependency Injection (Built-in)**: First-class DI container in ASP.NET Core (`IServiceCollection`)
## Import Patterns
- `using System.Collections.Generic` — import a namespace for unqualified type access
- `using static System.Math` — import static members for direct method access
- `global using` — file-scoped usings applied to the entire project (C# 10)
- `using Alias = Namespace.Type` — type alias for disambiguation
## File Patterns
- `*.csproj` — MSBuild project file defining targets, packages, and build properties
- `*.sln` — Visual Studio solution file grouping multiple projects
- `Program.cs` — application entry point (top-level statements in .NET 6+)
- `Startup.cs` — service and middleware configuration (older ASP.NET Core pattern)
- `appsettings.json` — hierarchical application configuration
## Common Frameworks
- **ASP.NET Core** — Cross-platform web framework for APIs, MVC, and Razor Pages
- **Entity Framework** — ORM with LINQ-to-SQL, migrations, and change tracking
- **Blazor** — Component-based UI framework using C# instead of JavaScript
- **MAUI** — Cross-platform native UI for mobile and desktop applications
- **xUnit** — Modern testing framework with theories, facts, and dependency injection
## Example Language Notes
> Uses LINQ method syntax `.Where().Select()` to compose a query pipeline over the
> collection. LINQ operations are lazily evaluated — the query only executes when
> results are enumerated, allowing efficient composition without intermediate allocations.
>
> The built-in DI container in ASP.NET Core registers services in `Program.cs` and
> resolves them via constructor injection, following the composition root pattern.

View File

@@ -0,0 +1,37 @@
# CSS Language Prompt Snippet
## Key Concepts
- **Selectors**: Element, class (`.name`), ID (`#name`), attribute (`[attr]`), and pseudo-class (`:hover`) targeting
- **Specificity**: Inline > ID > Class > Element cascade priority determining which rules win
- **Box Model**: `margin`, `border`, `padding`, `content` dimensions controlling element sizing
- **Flexbox**: `display: flex` with `justify-content`, `align-items` for one-dimensional layouts
- **Grid**: `display: grid` with `grid-template-columns/rows` for two-dimensional layouts
- **Custom Properties (Variables)**: `--name: value` with `var(--name)` for reusable design tokens
- **Media Queries**: `@media (max-width: ...)` for responsive design breakpoints
- **SCSS/Sass Features**: Nesting, `$variables`, `@mixin`, `@include`, `@extend`, `@use`, `@forward`
- **CSS Modules**: Scoped class names (`.module.css`) preventing global style collisions
- **Cascade Layers**: `@layer` for explicit control over cascade ordering
## Notable File Patterns
- `*.css` — Standard CSS stylesheets
- `*.scss` / `*.sass` — Sass/SCSS preprocessor files
- `*.less` — Less preprocessor files
- `*.module.css` / `*.module.scss` — CSS Modules (scoped styles)
- `globals.css` / `reset.css` / `normalize.css` — Global base styles
- `tailwind.config.js` — Tailwind CSS configuration (though a JS file)
- `variables.scss` / `_variables.scss` — Design token definitions
## Edge Patterns
- CSS files are `related` to the HTML or component files that import them for styling
- SCSS partial files (`_*.scss`) are `depends_on` by the main stylesheet that `@use`s them
- CSS variable definition files are `related` to all stylesheets that reference those variables
- CSS Modules are `related` to the component files that import them
## Summary Style
> "Global stylesheet defining CSS custom properties for the design system color palette and typography."
> "Responsive layout styles with flexbox and grid for the dashboard page across 3 breakpoints."
> "SCSS partial defining shared mixins for spacing, shadows, and media query breakpoints."

View File

@@ -0,0 +1,34 @@
# Dockerfile Language Prompt Snippet
## Key Concepts
- **Multi-Stage Builds**: Multiple `FROM` statements to separate build and runtime stages, reducing image size
- **Layer Caching**: Each instruction creates a layer; order instructions from least to most frequently changing for cache efficiency
- **Base Images**: `FROM image:tag` selects the starting image; prefer slim/alpine variants for smaller images
- **COPY vs ADD**: `COPY` for local files (preferred), `ADD` for URLs and tar extraction
- **Build Arguments**: `ARG` for build-time variables, `ENV` for runtime environment variables
- **Health Checks**: `HEALTHCHECK` instruction for container orchestrator readiness probes
- **Entry Point vs CMD**: `ENTRYPOINT` sets the executable, `CMD` provides default arguments
- **User Permissions**: `USER` instruction to run as non-root for security
- **Ignore Patterns**: `.dockerignore` excludes files from the build context (like `.gitignore`)
## Notable File Patterns
- `Dockerfile` — Primary container image definition (at project root)
- `Dockerfile.dev` / `Dockerfile.prod` — Environment-specific Dockerfiles
- `docker-compose.yml` — Multi-container application orchestration
- `docker-compose.override.yml` — Local development overrides
- `.dockerignore` — Build context exclusion patterns
## Edge Patterns
- Dockerfile `deploys` the application entry point it packages (COPY/CMD target)
- docker-compose `depends_on` Dockerfile(s) it references for building
- Dockerfile `depends_on` package manifests (package.json, requirements.txt) it copies for dependency installation
- docker-compose services create `related` edges between co-deployed components
## Summary Style
> "Multi-stage Docker build producing a minimal Node.js production image with N build stages."
> "Docker Compose configuration orchestrating N services with shared networking and persistent volumes."
> "Development Dockerfile with hot-reload support and mounted source volumes."

View File

@@ -0,0 +1,47 @@
# Go Language Prompt Snippet
## Key Concepts
- **Goroutines**: Lightweight concurrent functions launched with `go` keyword
- **Channels**: Typed conduits for communication and synchronization between goroutines
- **Interfaces**: Implicitly satisfied contracts — no `implements` keyword needed
- **Struct Embedding**: Composition mechanism providing field and method promotion
- **Error Handling**: Explicit error return values (`error` interface) instead of exceptions
- **Defer/Panic/Recover**: Deferred cleanup, unrecoverable errors, and recovery mechanism
- **Slices vs Arrays**: Arrays are fixed-size values; slices are dynamic views backed by arrays
- **Pointers**: Explicit pointer types for pass-by-reference semantics (no pointer arithmetic)
- **Context Propagation**: `context.Context` carries deadlines, cancellation, and request-scoped values
- **Init Functions**: Package-level `init()` runs automatically before `main()` for setup
## Import Patterns
- `import "package"` — single package import
- `import alias "package"` — aliased import to avoid name conflicts
- `import ( ... )` — grouped import block (standard library, then external, then internal)
- `import _ "package"` — blank import for side effects only (e.g., driver registration)
## File Patterns
- `*_test.go` — test files in the same package (or `_test` package for black-box tests)
- `cmd/` — directory containing main packages (binary entry points)
- `internal/` — packages only importable by parent module (enforced by compiler)
- `pkg/` — public library packages (convention, not enforced)
- `go.mod` — module definition with dependency versions
- `go.sum` — cryptographic checksums for dependencies
## Common Frameworks
- **Gin** — High-performance HTTP framework with middleware support
- **Echo** — Minimalist web framework with built-in middleware
- **Fiber** — Express-inspired framework built on fasthttp
- **Chi** — Lightweight, composable HTTP router
- **GORM** — ORM library with associations, hooks, and migrations
## Example Language Notes
> Implements `io.Reader` interface implicitly — no explicit declaration needed, just
> matching method signatures. This enables any type with a `Read([]byte) (int, error)`
> method to be used wherever `io.Reader` is expected.
>
> The `internal/` directory enforces encapsulation at the compiler level, preventing
> external packages from importing implementation details — stronger than naming convention.

View File

@@ -0,0 +1,35 @@
# GraphQL Language Prompt Snippet
## Key Concepts
- **Type System**: Strongly typed schema defining the API contract with scalar, object, enum, and union types
- **Queries**: Read operations fetching data with field-level selection (no over-fetching)
- **Mutations**: Write operations for creating, updating, and deleting data
- **Subscriptions**: Real-time data push over WebSocket connections
- **Resolvers**: Functions mapping schema fields to data sources (database, API, cache)
- **Fragments**: Reusable field selections reducing query duplication across operations
- **Directives**: `@deprecated`, `@include`, `@skip` for conditional field inclusion and schema metadata
- **Input Types**: `input` keyword for complex mutation arguments
- **Interfaces and Unions**: Polymorphic types for shared fields across multiple object types
- **Schema Stitching / Federation**: Composing multiple GraphQL services into a unified graph
## Notable File Patterns
- `schema.graphql` / `*.graphql` — Schema definition files
- `*.gql` — Alternative extension for GraphQL files
- `schema/*.graphql` — Split schema files by domain (users.graphql, orders.graphql)
- `*.resolvers.ts` / `*.resolvers.js` — Resolver implementations (TypeScript/JavaScript convention)
- `codegen.yml` — GraphQL Code Generator configuration
## Edge Patterns
- GraphQL schema files `defines_schema` for the resolver code that implements query/mutation handlers
- Type definitions create `related` edges between types connected by field references
- Schema files `defines_schema` for client-side query/mutation files that consume the API
- Codegen config `configures` the schema-to-code generation pipeline
## Summary Style
> "GraphQL schema defining N types, M queries, and K mutations for the user management API."
> "API schema with type definitions for products, orders, and payment processing with pagination."
> "Subscription schema enabling real-time notifications for order status updates."

View File

@@ -0,0 +1,34 @@
# HTML Language Prompt Snippet
## Key Concepts
- **Semantic Elements**: `<main>`, `<nav>`, `<header>`, `<footer>`, `<article>`, `<section>` for meaningful structure
- **Document Structure**: `<!DOCTYPE html>`, `<html>`, `<head>`, `<body>` forming the page skeleton
- **Forms**: `<form>`, `<input>`, `<select>`, `<textarea>` for user data collection with validation attributes
- **Accessibility**: `aria-*` attributes, `role`, `alt` text, and semantic markup for screen readers
- **Meta Tags**: `<meta>` for viewport, charset, description, Open Graph, and SEO metadata
- **Script and Style Loading**: `<script>`, `<link>`, `<style>` for JavaScript and CSS inclusion
- **Data Attributes**: `data-*` custom attributes for storing element-specific data
- **Template Syntax**: Framework-specific templating (`{{ }}` for Jinja/Django, `<%= %>` for ERB)
- **Web Components**: `<template>`, `<slot>`, Custom Elements for encapsulated reusable components
## Notable File Patterns
- `index.html` — Application entry point or SPA shell
- `*.html` / `*.htm` — Static HTML pages
- `templates/**/*.html` — Server-side template files (Django, Jinja2, Go templates)
- `public/index.html` — SPA root document (React, Vue)
- `*.ejs` / `*.hbs` / `*.pug` — Templating engine files
## Edge Patterns
- HTML files `depends_on` JavaScript and CSS files they include via `<script>` and `<link>` tags
- Template HTML files `depends_on` the server-side code that renders them
- HTML entry points are `deploys` targets for build systems and web servers
- HTML files `related` to the components or routes they render
## Summary Style
> "Single-page application shell with viewport meta, CSS reset, and React root mount point."
> "Server-rendered template with navigation, content area, and footer using Django template inheritance."
> "Static landing page with responsive layout, form, and third-party script integrations."

View File

@@ -0,0 +1,45 @@
# Java Language Prompt Snippet
## Key Concepts
- **Generics (with Erasure)**: Parameterized types erased at runtime; compile-time safety only
- **Annotations**: Metadata markers (`@Override`, `@Autowired`) processed at compile or runtime
- **Interfaces and Abstract Classes**: Contracts with default methods (Java 8+) and partial implementations
- **Streams API**: Functional-style pipeline operations on collections (filter, map, reduce)
- **Lambdas**: Concise anonymous function syntax for functional interfaces
- **Sealed Classes**: Restricted class hierarchies with explicit permitted subclasses (Java 17+)
- **Records**: Immutable data carriers with auto-generated accessors, equals, hashCode (Java 16+)
- **Dependency Injection**: IoC pattern central to Spring; constructor, field, or method injection
- **Checked vs Unchecked Exceptions**: Checked must be declared or caught; unchecked extend RuntimeException
- **Optional**: Container for nullable values encouraging explicit handling over null checks
## Import Patterns
- `import package.Class` — import a specific class
- `import package.*` — wildcard import of all classes in a package
- `import static package.Class.method` — static import for direct method/constant access
## File Patterns
- `src/main/java/` — source root following Maven/Gradle standard layout
- `src/test/java/` — test source root with matching package structure
- `pom.xml` — Maven project configuration and dependency management
- `build.gradle` — Gradle build script (Groovy or Kotlin DSL)
- `Application.java` — Spring Boot entry point with `@SpringBootApplication`
## Common Frameworks
- **Spring Boot** — Opinionated framework for production-ready Spring applications
- **Jakarta EE** — Enterprise Java standards (formerly Java EE) for server-side development
- **Quarkus** — Cloud-native framework optimized for GraalVM and containers
- **Micronaut** — Compile-time DI framework for microservices and serverless
- **Hibernate** — ORM framework implementing JPA specification
## Example Language Notes
> Uses `@Autowired` annotation for constructor injection, following Spring IoC container
> pattern. Constructor injection is preferred over field injection because it makes
> dependencies explicit and enables immutability.
>
> The Maven standard directory layout (`src/main/java`, `src/test/java`) is a strong
> convention — most build tools and IDEs expect this structure by default.

View File

@@ -0,0 +1,46 @@
# JavaScript Language Prompt Snippet
## Key Concepts
- **Closures**: Functions that capture variables from their enclosing lexical scope
- **Prototypes**: Prototype chain-based inheritance underlying all JavaScript objects
- **Promises**: Asynchronous value containers enabling `.then()` chaining and `async/await`
- **Event Loop**: Single-threaded concurrency model with microtask and macrotask queues
- **Destructuring**: Extract values from objects and arrays into distinct variables
- **Spread/Rest Operators**: `...` for expanding iterables or collecting remaining arguments
- **Proxies**: Meta-programming construct to intercept and customize object operations
- **Generators**: Functions using `function*` and `yield` for lazy iteration
- **Symbol**: Unique, immutable primitive used for non-string property keys
- **WeakMap/WeakSet**: Collections with weakly-held keys allowing garbage collection
- **Modules (ESM vs CJS)**: ES Modules use `import/export`; CommonJS uses `require/module.exports`
## Import Patterns
- `import { X } from 'module'` — ESM named import
- `const X = require('module')` — CommonJS require
- `import('module')` — dynamic import returning a Promise (code splitting)
- `export default X` / `export { X }` — ESM export forms
## File Patterns
- `index.js` — barrel file or directory entry point
- `.mjs` — explicitly ES Module files
- `.cjs` — explicitly CommonJS files
- `package.json` `"type"` field — sets default module system (`"module"` or `"commonjs"`)
## Common Frameworks
- **React** — Declarative UI with virtual DOM and component model
- **Vue** — Progressive framework with reactivity system and single-file components
- **Express** — Minimal and flexible Node.js web application framework
- **Next.js** — React framework for production with hybrid rendering
- **Svelte** — Compile-time framework that shifts work from runtime to build step
## Example Language Notes
> Closure captures outer `config` variable, providing encapsulated state without class
> overhead. The returned object's methods share access to the same `config` reference,
> forming a module pattern that was standard before ES Modules.
>
> When encountering `.mjs` vs `.cjs` extensions, the module system is determined by
> extension regardless of the `package.json` type field — useful in mixed codebases.

View File

@@ -0,0 +1,34 @@
# JSON Language Prompt Snippet
## Key Concepts
- **Strict Syntax**: No trailing commas, no comments (unlike JSONC or JSON5), double-quoted strings only
- **Data Types**: Objects, arrays, strings, numbers, booleans, and null — no undefined or date types
- **Nested Structure**: Arbitrary nesting depth for hierarchical configuration or data
- **Schema Validation**: JSON Schema (`$schema` keyword) for validating structure and types
- **JSONC**: JSON with Comments variant used by VS Code, tsconfig.json, and other tooling
- **JSON5**: Extended JSON allowing comments, trailing commas, unquoted keys, and more
- **JSON Lines** (`.jsonl`): One JSON object per line for streaming data processing
## Notable File Patterns
- `package.json` — Node.js project manifest with dependencies, scripts, and metadata
- `tsconfig.json` — TypeScript compiler configuration (actually JSONC)
- `.eslintrc.json` — ESLint linting rules and configuration
- `*.schema.json` — JSON Schema definitions for validation
- `composer.json` — PHP Composer project manifest
- `appsettings.json` — .NET application configuration
- `manifest.json` — Browser extension or PWA manifest
## Edge Patterns
- `package.json` `configures` the build toolchain and defines project dependencies
- `tsconfig.json` `configures` TypeScript compilation for all `.ts` files
- JSON Schema files `defines_schema` for API request/response validation
- Config JSON files `configures` the runtime behavior of the application
## Summary Style
> "Node.js project manifest defining N dependencies, build scripts, and project metadata."
> "TypeScript compiler configuration enabling strict mode with path aliases for monorepo packages."
> "JSON Schema defining the request/response structure for the user API endpoint."

View File

@@ -0,0 +1,45 @@
# Kotlin Language Prompt Snippet
## Key Concepts
- **Coroutines and Flow**: Structured concurrency with suspending functions; Flow for reactive streams
- **Data Classes**: Auto-generated `equals`, `hashCode`, `toString`, `copy`, and destructuring
- **Sealed Classes/Interfaces**: Restricted hierarchies enabling exhaustive `when` expressions
- **Extension Functions**: Add methods to existing classes without inheritance or wrappers
- **Null Safety**: `?.` safe call, `!!` non-null assertion, `?:` Elvis operator for default values
- **Delegation (by keyword)**: Delegate interface implementation or property access to another object
- **DSL Builders**: Lambda-with-receiver syntax enabling type-safe builder patterns
- **Inline Functions and Reified Types**: Inline for zero-overhead lambdas; reified for runtime type access
- **Companion Objects**: Named or anonymous singleton associated with a class (replaces static members)
- **Scope Functions**: `let`, `run`, `apply`, `also`, `with` for concise object configuration and transformation
## Import Patterns
- `import package.ClassName` — import a specific class
- `import package.*` — wildcard import of all declarations in a package
- `import package.function as alias` — import with alias to resolve naming conflicts
## File Patterns
- `build.gradle.kts` — Gradle build script using Kotlin DSL
- `Application.kt` — application entry point (Spring Boot or Ktor)
- `src/main/kotlin/` — main source root following Gradle conventions
- `src/test/kotlin/` — test source root with matching package structure
- `settings.gradle.kts` — multi-module project configuration
## Common Frameworks
- **Spring Boot (Kotlin)** — Kotlin-first support with coroutines and DSL extensions
- **Ktor** — Kotlin-native async web framework from JetBrains
- **Jetpack Compose** — Declarative UI toolkit for Android using composable functions
- **Exposed** — Lightweight SQL framework with type-safe DSL and DAO patterns
- **Koin** — Pragmatic dependency injection framework using Kotlin DSL
## Example Language Notes
> Uses sealed class hierarchy with `when` exhaustive matching to handle all possible
> API response states. The compiler enforces that every variant is covered, eliminating
> the need for a fallback `else` branch and catching missing cases at compile time.
>
> Extension functions allow adding utilities like `String.toSlug()` without modifying
> the original class — keeping the extension discoverable through IDE auto-complete.

View File

@@ -0,0 +1,34 @@
# Markdown Language Prompt Snippet
## Key Concepts
- **Heading Hierarchy**: `#` through `######` for document structure, with h1 as the title
- **Front Matter**: YAML metadata between `---` delimiters at the top of the file
- **Fenced Code Blocks**: Triple backticks with optional language identifier for syntax highlighting
- **Reference-Style Links**: `[text][ref]` with `[ref]: url` definitions, useful for repeated URLs
- **Tables**: Pipe-delimited columns with alignment markers (`:---`, `:---:`, `---:`)
- **Admonitions**: Blockquote-based callouts (`> **Note:**`, `> **Warning:**`) for emphasis
- **Task Lists**: `- [ ]` and `- [x]` for checklists in issue trackers and READMEs
- **HTML Embedding**: Raw HTML allowed inline for features Markdown does not support natively
## Notable File Patterns
- `README.md` — Project overview and entry point for new contributors (high-value)
- `CONTRIBUTING.md` — Contribution guidelines, code style, PR process
- `CHANGELOG.md` — Version history following Keep a Changelog or similar format
- `docs/**/*.md` — Documentation directory with guides, API references, tutorials
- `*.md` in source directories — Co-located documentation for modules or packages
- `ADR-*.md` or `adr/*.md` — Architecture Decision Records
## Edge Patterns
- Markdown files `documents` the code components they describe or reference
- Links to other `.md` files create `related` edges between documentation nodes
- Code block references mentioning file paths may imply `documents` edges to those files
- README files in subdirectories typically `documents` the module at that path
## Summary Style
> "Project overview documentation with N sections covering installation, usage, and API reference."
> "Architecture Decision Record documenting the choice of [technology] for [purpose]."
> "Contributing guide with code style rules, testing requirements, and pull request process."

View File

@@ -0,0 +1,46 @@
# PHP Language Prompt Snippet
## Key Concepts
- **Namespaces**: Organize code and prevent naming collisions using backslash-delimited paths
- **Traits**: Horizontal code reuse mechanism for sharing methods across unrelated classes
- **Type Declarations**: Parameter, return, and property types (scalar, union, intersection types)
- **Attributes (PHP 8+)**: Native metadata annotations replacing docblock-based configuration
- **Enums (PHP 8.1+)**: First-class enumeration types with methods and interface implementation
- **Fibers**: Lightweight cooperative concurrency primitives for non-blocking I/O
- **Closures/Anonymous Functions**: First-class functions with explicit `use` for variable capture
- **Magic Methods**: Special methods like `__construct`, `__get`, `__set`, `__call` for object behavior
- **Dependency Injection**: Constructor injection managed by PSR-11 compatible containers
- **Middleware**: Request/response pipeline pattern central to modern PHP frameworks
## Import Patterns
- `use Namespace\ClassName` — import a class by its fully qualified name
- `use Namespace\ClassName as Alias` — import with an alias to avoid conflicts
- `namespace App\Http\Controllers` — declare the current file's namespace
- `use function Namespace\functionName` — import a namespaced function
## File Patterns
- `composer.json` — dependency management and PSR-4 autoloading configuration
- `index.php` — web application entry point (front controller)
- `artisan` — Laravel CLI entry point for commands and migrations
- `routes/` — route definition files (web.php, api.php in Laravel)
- PSR-4 autoloading maps namespace prefixes to directory paths
## Common Frameworks
- **Laravel** — Full-featured framework with Eloquent ORM, Blade templates, and queues
- **Symfony** — Component-based framework powering many PHP projects and libraries
- **WordPress** — CMS platform with hook-based plugin architecture
- **Slim** — Micro-framework for APIs and small applications
- **CodeIgniter** — Lightweight MVC framework with minimal configuration
## Example Language Notes
> Uses PHP 8 attributes `#[Route('/api/users')]` for declarative route mapping on
> controller methods. Attributes replace the older docblock annotation pattern,
> providing native language support for metadata that tools can reflect upon.
>
> PSR-4 autoloading in `composer.json` maps `App\` to `src/`, so the class
> `App\Http\Controllers\UserController` loads from `src/Http/Controllers/UserController.php`.

View File

@@ -0,0 +1,34 @@
# Protobuf Language Prompt Snippet
## Key Concepts
- **Message Types**: `message` blocks defining structured data with typed, numbered fields
- **Field Numbers**: Permanent identifiers (1-536870911) — never reuse deleted numbers for backward compatibility
- **Scalar Types**: `int32`, `int64`, `string`, `bytes`, `bool`, `float`, `double`, and more
- **Enums**: Named integer constants for categorical values
- **Services**: `service` blocks defining RPC (Remote Procedure Call) method signatures
- **Oneof**: Mutually exclusive field groups — only one field in the group can be set
- **Repeated Fields**: `repeated` keyword for list/array fields
- **Maps**: `map<key_type, value_type>` for dictionary/hash fields
- **Packages and Imports**: Namespace organization and cross-file references
- **Proto2 vs Proto3**: Proto3 (current) removes required/optional distinction and defaults all fields
## Notable File Patterns
- `*.proto` — Protocol Buffer definition files
- `proto/**/*.proto` — Organized proto definitions by service or domain
- `buf.yaml` / `buf.gen.yaml` — Buf tool configuration for linting and code generation
- `*_pb2.py` / `*.pb.go` / `*_pb.ts` — Generated code (should be excluded from analysis)
## Edge Patterns
- Protobuf files `defines_schema` for the gRPC service handlers that implement the declared RPCs
- Message type references create `related` edges between proto files sharing types
- Proto `import` statements create `depends_on` edges between proto files
- Generated code files are `depends_on` the proto source that produces them
## Summary Style
> "Protocol Buffer definitions for N message types and M RPC services in the user authentication domain."
> "Shared proto types defining common request/response envelopes and error codes."
> "gRPC service definition with N methods for real-time data streaming and batch processing."

View File

@@ -0,0 +1,48 @@
# Python Language Prompt Snippet
## Key Concepts
- **Decorators**: Functions that wrap other functions or classes using `@decorator` syntax
- **List/Dict Comprehensions**: Concise syntax for creating collections from iterables
- **Generators and Yield**: Lazy iterators using `yield` for memory-efficient data processing
- **Context Managers**: `with` statement for resource management via `__enter__`/`__exit__`
- **Type Hints and Typing Module**: Optional static type annotations for tooling and documentation
- **Dunder Methods**: Special methods like `__init__`, `__repr__`, `__eq__` defining object behavior
- **Metaclasses**: Classes that define how other classes are created (type as default metaclass)
- **Dataclasses**: `@dataclass` decorator auto-generating boilerplate from field annotations
- **Protocols**: Structural subtyping via `typing.Protocol` for duck-type-safe interfaces
- **Descriptors**: Objects defining `__get__`, `__set__`, `__delete__` to customize attribute access
- **Async/Await with Asyncio**: Cooperative concurrency using coroutines and an event loop
## Import Patterns
- `from module import name` — import specific name from module
- `import module` — import entire module, access via `module.name`
- `from package.module import name` — absolute import from nested package
- `from . import relative` — relative import within a package
## File Patterns
- `__init__.py` — package initializer (barrel equivalent), can re-export public API
- `__main__.py` — package entry point when run with `python -m package`
- `conftest.py` — pytest shared fixtures and hooks (auto-discovered)
- `setup.py` / `pyproject.toml` — project configuration and build metadata
- `requirements.txt` — pinned dependency list
## Common Frameworks
- **Django** — Full-stack web framework with ORM, admin, and batteries included
- **FastAPI** — Modern async API framework with automatic OpenAPI docs
- **Flask** — Lightweight WSGI micro-framework for web applications
- **SQLAlchemy** — SQL toolkit and ORM with unit-of-work pattern
- **Celery** — Distributed task queue for background job processing
- **Pydantic** — Data validation and settings management using type annotations
## Example Language Notes
> Uses `@dataclass` decorator to auto-generate `__init__`, `__repr__`, and `__eq__` from
> field annotations. This eliminates boilerplate while keeping the class definition
> readable and the generated methods consistent.
>
> When `__init__.py` re-exports symbols, it acts as the package's public API surface —
> consumers import from the package rather than reaching into internal modules.

View File

@@ -0,0 +1,46 @@
# Ruby Language Prompt Snippet
## Key Concepts
- **Blocks/Procs/Lambdas**: First-class callable objects; blocks are implicit, procs and lambdas are explicit
- **Mixins (include/extend)**: Share behavior across classes via modules without inheritance
- **Metaprogramming**: Dynamic method definition (`define_method`), interception (`method_missing`)
- **Duck Typing**: Objects are defined by what they can do, not what class they are
- **DSLs**: Domain-specific languages built using blocks and metaprogramming (e.g., Rails routes)
- **Monkey Patching**: Reopening existing classes to add or modify methods at runtime
- **Symbols**: Immutable, interned strings (`:name`) used as identifiers and hash keys
- **Open Classes**: Any class can be reopened and extended at any point in the program
- **Enumerable Module**: Mixin providing collection methods (map, select, reduce) to any class with `each`
## Import Patterns
- `require 'gem_name'` — load a gem or standard library module
- `require_relative './file'` — load a file relative to the current file's directory
- `load 'file.rb'` — load and re-execute a file (unlike require, does not cache)
- `autoload :ClassName, 'path'` — lazy loading of constants on first reference
## File Patterns
- `Gemfile` — dependency declarations managed by Bundler
- `Rakefile` — task definitions (Ruby's make equivalent)
- `spec/` — RSpec test directory with `*_spec.rb` convention
- `test/` — Minitest directory with `test_*.rb` or `*_test.rb` convention
- `config.ru` — Rack application entry point for web servers
- `lib/` — main source code directory by convention
## Common Frameworks
- **Rails** — Full-stack web framework following convention over configuration
- **Sinatra** — Minimal DSL for creating web applications quickly
- **RSpec** — Behavior-driven testing framework with expressive DSL
- **Sidekiq** — Background job processing using Redis-backed queues
- **Grape** — REST API micro-framework for Ruby
## Example Language Notes
> Uses `method_missing` to dynamically delegate attribute access to the wrapped model
> object. When a method is not found on the decorator, it falls through to the model,
> providing transparent delegation without explicit forwarding methods.
>
> Rails relies heavily on convention over configuration — file placement in `app/models/`,
> `app/controllers/`, etc. determines behavior without explicit registration.

View File

@@ -0,0 +1,47 @@
# Rust Language Prompt Snippet
## Key Concepts
- **Ownership and Borrowing**: Each value has one owner; references borrow without taking ownership
- **Lifetimes**: Annotations (`'a`) ensuring references remain valid for their required duration
- **Traits and Trait Objects**: Shared behavior definitions; `dyn Trait` for dynamic dispatch
- **Pattern Matching**: Exhaustive `match` expressions deconstructing enums, structs, and tuples
- **Enums with Data**: Algebraic data types — each variant can carry different associated data
- **Result/Option Error Handling**: `Result<T, E>` for fallible ops; `Option<T>` for nullable values
- **Macros**: Declarative (`macro_rules!`) and procedural (derive, attribute, function-like) code generation
- **Async/Await with Tokio**: Zero-cost async using `Future` trait and runtime executors
- **Unsafe Blocks**: Opt-in blocks for raw pointer dereferencing, FFI, and bypassing borrow checker
- **Generics with Trait Bounds**: `<T: Clone + Send>` constraining generic parameters
- **Closures and Fn Traits**: `Fn`, `FnMut`, `FnOnce` determine how closures capture environment
## Import Patterns
- `use crate::module::Item` — import from current crate
- `use std::collections::HashMap` — import from standard library
- `use super::*` — import everything from parent module
- `mod module_name` — declare a submodule (loads from file)
## File Patterns
- `mod.rs` — module barrel file (older convention) or `module_name.rs` (2018+ edition)
- `lib.rs` — library crate root defining the public API
- `main.rs` — binary crate entry point
- `Cargo.toml` — project manifest with dependencies and metadata
- `build.rs` — build script executed before compilation
## Common Frameworks
- **Actix-web** — Actor-based, high-performance web framework
- **Axum** — Ergonomic web framework built on Tower and Hyper
- **Rocket** — Type-safe web framework with declarative routing
- **Diesel** — Safe, composable ORM and query builder
- **Tokio** — Async runtime providing I/O, timers, and task scheduling
## Example Language Notes
> Takes `&self` borrow to read state without transferring ownership; returns
> `Result<T, Error>` for explicit error propagation. The `?` operator propagates
> errors up the call stack concisely, replacing verbose match blocks.
>
> The module system maps to the filesystem: `mod handlers;` loads either
> `handlers.rs` or `handlers/mod.rs`, establishing the module tree at compile time.

View File

@@ -0,0 +1,35 @@
# Shell Language Prompt Snippet
## Key Concepts
- **Shebang Line**: `#!/bin/bash` or `#!/usr/bin/env bash` specifying the interpreter
- **Variables**: `VAR=value` assignment, `$VAR` or `${VAR}` expansion, no spaces around `=`
- **Functions**: `function name()` or `name()` for reusable command groups
- **Conditionals**: `if [[ condition ]]; then ... fi` with `[[ ]]` for extended tests
- **Loops**: `for item in list`, `while condition`, `until condition` iteration patterns
- **Pipes and Redirection**: `|` for chaining commands, `>` / `>>` / `2>&1` for output redirection
- **Exit Codes**: `$?` captures last command status; `set -e` exits on any failure
- **Strict Mode**: `set -euo pipefail` for robust error handling (exit on error, undefined vars, pipe failures)
- **Command Substitution**: `$(command)` captures command output as a string
- **Here Documents**: `<<EOF ... EOF` for multi-line string input to commands
## Notable File Patterns
- `*.sh` / `*.bash` — Shell script files
- `scripts/*.sh` — Project automation scripts (build, deploy, setup)
- `entrypoint.sh` — Docker container entry point script
- `install.sh` / `setup.sh` — Environment setup scripts
- `.bashrc` / `.bash_profile` / `.zshrc` — Shell configuration files
## Edge Patterns
- Shell scripts `triggers` other scripts or build processes they invoke
- Entry point scripts `deploys` the application they start
- Setup scripts `configures` the development environment
- Build scripts `depends_on` the source files they compile or package
## Summary Style
> "Build automation script compiling TypeScript, running tests, and packaging the release artifact."
> "Docker entry point script handling signal forwarding and graceful shutdown."
> "Environment setup script installing dependencies and configuring development tools."

View File

@@ -0,0 +1,36 @@
# SQL Language Prompt Snippet
## Key Concepts
- **DDL (Data Definition)**: `CREATE TABLE`, `ALTER TABLE`, `DROP TABLE` for schema management
- **DML (Data Manipulation)**: `SELECT`, `INSERT`, `UPDATE`, `DELETE` for data operations
- **Normalization**: Organizing tables to reduce redundancy through 1NF, 2NF, 3NF relationships
- **Foreign Keys**: `REFERENCES` constraints enforcing referential integrity between tables
- **Indexes**: `CREATE INDEX` for query performance optimization on frequently queried columns
- **Migrations**: Numbered, sequential schema changes applied in order for version control
- **Transactions**: `BEGIN`/`COMMIT`/`ROLLBACK` for atomic multi-statement operations
- **Views**: Named queries (`CREATE VIEW`) providing virtual tables for complex joins
- **Stored Procedures**: Server-side functions for encapsulating business logic in the database
- **Constraints**: `NOT NULL`, `UNIQUE`, `CHECK`, `DEFAULT` for data integrity rules
## Notable File Patterns
- `migrations/*.sql` — Numbered migration files (e.g., `001_create_users.sql`, `002_add_orders.sql`)
- `schema.sql` — Full database schema definition (often generated from migrations)
- `seeds/*.sql` — Seed data for development and testing environments
- `*.up.sql` / `*.down.sql` — Reversible migration pairs (up applies, down reverts)
- `init.sql` — Database initialization script for Docker or fresh setup
- `procedures/*.sql` — Stored procedure definitions
## Edge Patterns
- SQL migration files `migrates` the tables they create or alter
- Schema definition files `defines_schema` for the ORM models or data layer code that reads them
- Table definitions create implicit `related` edges between tables connected by foreign keys
- Seed files `depends_on` the migration files that create the tables they populate
## Summary Style
> "Database migration creating the users table with email, name, and authentication columns."
> "Schema definition with N tables covering user management, orders, and payment processing."
> "Seed data populating N tables with development fixtures for testing."

View File

@@ -0,0 +1,46 @@
# Swift Language Prompt Snippet
## Key Concepts
- **Optionals and Optional Chaining**: `Type?` wraps values that may be nil; `?.` chains safely
- **Protocols and Protocol Extensions**: Define contracts with default implementations via extensions
- **Value Types vs Reference Types**: Structs and enums are value types; classes are reference types
- **Closures**: Self-contained blocks of functionality that capture surrounding context
- **Property Wrappers**: `@State`, `@Binding`, `@Published` encapsulate property storage logic
- **Result Builders**: `@ViewBuilder`, `@resultBuilder` enable declarative DSL syntax
- **Actors and Structured Concurrency**: `actor` types for data isolation; `async let`, `TaskGroup`
- **Generics**: Type parameters with `where` clauses and associated type constraints
- **Enums with Associated Values**: Each case can carry distinct typed payloads
- **Extensions**: Add methods, computed properties, and protocol conformance to existing types
## Import Patterns
- `import Foundation` — core library with data types, collections, networking
- `import UIKit` — iOS UI framework for traditional view controller architecture
- `import SwiftUI` — declarative UI framework with reactive state management
- `@testable import ModuleName` — import with internal access for unit testing
## File Patterns
- `Package.swift` — Swift Package Manager manifest defining targets and dependencies
- `*.xcodeproj` / `*.xcworkspace` — Xcode project and workspace configuration
- `AppDelegate.swift` — UIKit application lifecycle entry point
- `App.swift` — SwiftUI application entry point using `@main`
- `Tests/` — test target directory following SPM or Xcode conventions
## Common Frameworks
- **SwiftUI** — Declarative UI framework with reactive data flow
- **UIKit** — Imperative UI framework using view controllers and Auto Layout
- **Vapor** — Server-side Swift web framework with async support
- **Combine** — Reactive framework for processing values over time
- **Core Data** — Object graph and persistence framework
## Example Language Notes
> Uses `@Published` property wrapper to automatically notify SwiftUI views of state
> changes. When the wrapped value mutates, the property wrapper triggers `objectWillChange`
> on the enclosing `ObservableObject`, causing dependent views to re-render.
>
> Protocol extensions provide default implementations, allowing types to conform by
> simply declaring conformance — no method body needed if defaults suffice.

View File

@@ -0,0 +1,38 @@
# Terraform Language Prompt Snippet
## Key Concepts
- **Declarative Infrastructure**: Define desired state; Terraform computes and applies the diff
- **Providers**: Plugins connecting to cloud APIs (AWS, GCP, Azure, Kubernetes, etc.)
- **Resources**: `resource "type" "name"` blocks declaring infrastructure components
- **Data Sources**: `data "type" "name"` blocks reading existing infrastructure state
- **Variables**: `variable` blocks for parameterizing configurations with defaults and validation
- **Outputs**: `output` blocks exposing values for cross-module references or human consumption
- **Modules**: Reusable, composable infrastructure packages with their own variables and outputs
- **State Management**: `.tfstate` files tracking real-world resource mapping (never commit to git)
- **Workspaces**: Isolated state environments for managing dev/staging/prod from one codebase
- **Plan and Apply**: `terraform plan` previews changes, `terraform apply` executes them
## Notable File Patterns
- `main.tf` — Primary resource definitions
- `variables.tf` — Input variable declarations with types and defaults
- `outputs.tf` — Output value definitions
- `providers.tf` — Provider configuration and version constraints
- `backend.tf` — Remote state backend configuration (S3, GCS, etc.)
- `modules/**/*.tf` — Reusable infrastructure modules
- `*.tfvars` — Variable value files for different environments
- `terraform.lock.hcl` — Provider version lock file
## Edge Patterns
- Terraform files `provisions` the infrastructure resources they define
- Module references create `depends_on` edges between terraform files
- Terraform `deploys` application code by referencing container images or deployment targets
- Variable files `configures` the terraform modules they parameterize
## Summary Style
> "Terraform configuration provisioning N AWS resources including VPC, ECS cluster, and RDS instance."
> "Infrastructure module defining a reusable Kubernetes namespace with RBAC and network policies."
> "Variable definitions for N environment-specific settings (region, instance type, scaling)."

View File

@@ -0,0 +1,46 @@
# TypeScript Language Prompt Snippet
## Key Concepts
- **Generics**: Parameterized types (`<T>`) enabling reusable, type-safe abstractions
- **Type Guards**: Runtime checks that narrow types within conditional blocks (`is`, `in`, `typeof`, `instanceof`)
- **Discriminated Unions**: Union types with a shared literal field used for exhaustive narrowing
- **Utility Types**: Built-in mapped types like `Partial<T>`, `Pick<T, K>`, `Omit<T, K>`, `Record<K, V>`
- **Interfaces vs Types**: Interfaces support declaration merging; type aliases support unions and mapped types
- **Enums**: Numeric and string enums for named constant sets; prefer `as const` objects when possible
- **Mapped Types**: Transform existing types property-by-property using `[K in keyof T]` syntax
- **Conditional Types**: `T extends U ? X : Y` for type-level branching logic
- **Template Literal Types**: String manipulation at the type level using backtick syntax
- **Declaration Merging**: Interfaces with the same name merge their members automatically
- **Module Augmentation**: Extending third-party module types via `declare module` blocks
## Import Patterns
- `import { X } from 'module'` — named import (most common)
- `import type { X } from 'module'` — type-only import (erased at runtime)
- `import * as X from 'module'` — namespace import
- `import X from 'module'` — default import
## File Patterns
- `index.ts` — barrel file re-exporting public API from a directory
- `*.d.ts` — type declaration files (ambient declarations, no runtime code)
- `tsconfig.json` — TypeScript compiler configuration and project references
- `*.tsx` — TypeScript files containing JSX (React components)
## Common Frameworks
- **React** — UI component library with hooks and JSX
- **Angular** — Full-featured framework with decorators and dependency injection
- **Next.js** — React meta-framework with SSR, SSG, and API routes
- **NestJS** — Server-side framework inspired by Angular (decorators, modules, DI)
- **Express (with TS)** — Minimal HTTP framework with typed request/response handlers
## Example Language Notes
> Uses generic type parameter `T extends BaseEntity` to ensure type safety across
> repository methods. The constraint guarantees all entities share a common `id` field
> while allowing specific entity types to flow through the data layer without casting.
>
> Barrel files (`index.ts`) re-export symbols so consumers import from the directory
> rather than reaching into internal module paths — maintaining encapsulation.

View File

@@ -0,0 +1,35 @@
# YAML Language Prompt Snippet
## Key Concepts
- **Indentation-Based Nesting**: Whitespace-sensitive structure (spaces only, no tabs) defining hierarchy
- **Anchors and Aliases**: `&anchor` defines a reusable block, `*anchor` references it to avoid duplication
- **Merge Keys**: `<<: *anchor` merges anchor contents into the current mapping
- **Multi-Line Strings**: Literal block (`|`) preserves newlines, folded block (`>`) joins lines
- **Document Separators**: `---` starts a new document, `...` ends one (multi-document streams)
- **Tags and Types**: `!!str`, `!!int`, `!!bool` for explicit typing; custom tags for application-specific types
- **Flow Style**: Inline JSON-like syntax `{key: value}` and `[item1, item2]` for compact notation
- **Environment Variable Substitution**: `${VAR}` patterns used in docker-compose and CI configs
## Notable File Patterns
- `docker-compose.yml` / `docker-compose.yaml` — Multi-container Docker application definition
- `.github/workflows/*.yml` — GitHub Actions CI/CD workflow definitions
- `.gitlab-ci.yml` — GitLab CI/CD pipeline configuration
- `kubernetes/*.yaml` / `k8s/*.yaml` — Kubernetes resource manifests
- `*.config.yaml` — Application configuration files
- `mkdocs.yml` — MkDocs documentation site configuration
- `serverless.yml` — Serverless Framework configuration
## Edge Patterns
- YAML config files `configures` the code modules they control (e.g., database settings affect data layer)
- CI/CD YAML files `triggers` build and deployment pipelines
- docker-compose YAML `deploys` services and `depends_on` Dockerfiles
- Kubernetes YAML `deploys` and `provisions` application services
## Summary Style
> "Docker Compose configuration defining N services with networking, volumes, and health checks."
> "GitHub Actions workflow running tests on push and deploying to production on merge to main."
> "Kubernetes deployment manifest with N replicas, resource limits, and liveness probes."