baldart 3.6.2

package/framework/AGENTS.md

@@ -0,0 +1,240 @@
+# Agent Protocol (AGENTS.md)
+
+Mandatory coordination rules for all agents (Codex/Claude/humans).
+Applies before, during, and after any work in this repo.
+If context is limited, follow MUST rules and Routing first.
+
+## Project Context (v3.0.0+)
+
+This file is generic. Paths referenced as `${paths.X}` resolve from `baldart.config.yml` in the repo root. MUST rules that target workflow infrastructure (backlog cards, ADRs, project-status doc, PRD sessions, LLM wiki overlay) apply **only when the matching `features.*` flag is `true`** in `baldart.config.yml`:
+
+| MUST topic | Active when |
+|---|---|
+| Backlog cards (`${paths.backlog_dir}/`), card status, file ownership | `features.has_backlog: true` |
+| ADRs (`${paths.adrs_dir}/`), architectural decision records | `features.has_adrs: true` |
+| `project-status.md` Active Code Context updates | the file exists at `${paths.references_dir}/project-status.md` |
+| PRD workflow, PRD sessions | `features.has_prd_workflow: true` |
+| LLM wiki overlay sync | `features.has_wiki_overlay: true` |
+| Design-system blocking reads | `features.has_design_system: true` |
+
+When a MUST rule's feature is `false` or its target file does not exist, the rule is **silent** — do not invent a workflow that isn't there. Project-specific terminology (audience segments, domain entities, brand voice) comes from `identity.audience_segments`, `agents/coding-standards.md`, and skill overlays under `.baldart/overlays/`. See `agents/project-context.md` for the full protocol.
+
+## Pre-Commit Checks
+
+Before committing, run only fast checks (lint + type check). Full build is required only before opening a PR. Fix all errors before staging files.
+
+## File Navigation
+
+When searching for files, use Glob/Grep to find actual file paths before reading. Never guess file paths based on naming conventions.
+
+## Git Workflow
+
+### Branching Strategy (Simplified Git Flow)
+
+This repo uses a simplified Git Flow.
+
+| Branch | Base | Merges To | Purpose |
+|--------|------|-----------|---------|
+| `main` | — | — | Production. No direct pushes. |
+| `develop` | `main` | `main` (release PR) | Integration branch for features. |
+| `feat/*` | `develop` | `develop` (PR) | Feature work per backlog card. |
+| `hotfix/*` | `main` | `main` + `develop` | Critical production fixes only. |
+
+### Branch Rules
+
+- **Feature work**: Branch from `develop` → `feat/FEAT-XXXX-slug` → PR to `develop`.
+- **Cloud agents**: Branch from `develop` → `codex/FEAT-XXXX-slug` or `claude/FEAT-XXXX-slug` → PR to `develop`.
+- **Hotfixes**: Branch from `main` → `hotfix/BUG-XXXX-slug` → PR to `main`, then merge/cherry-pick to `develop`.
+- **Releases**: PR from `develop` → `main` when a set of features is ready for production.
+- **Direct push to `main` is blocked** by a pre-push hook. Use `--no-verify` only for documented emergencies.
+
+### Commit Hygiene
+
+Before committing, ensure only files related to the current task are staged. Run `git status` and `git diff --staged` to verify. Never bundle unrelated changes into a commit.
+
+## Investigation Guidelines
+
+When investigating whether a feature has been implemented, always check git history (`git log --oneline --all --grep`) and actual source code before claiming it exists or doesn't exist.
+
+## Implementation Completeness
+
+When implementing a backlog card or feature plan, verify ALL items from the plan are wired up and functional before marking complete. Cross-check each acceptance criterion against the actual code.
+
+## Testing Conventions
+
+When tests exist, always run the full test suite after implementation to check for regressions. If a test fails, fix the code — not the test — unless the test itself is wrong. When writing new features with tests, write failing tests first, then implement the minimum code to pass them.
+
+## 2) Priority order & conflict policy
+
+Priority order for conflicts:
+- Agent rules: `AGENTS.md`.
+- Routing: `agents/index.md`.
+- Domain references: `${paths.references_dir}/*` (data-model, api/, ui-pages, product-scope, project-status).
+- Decisions: `${paths.adrs_dir}/ADR-YYYYMMDD-*.md`.
+- Legacy: `archive/project_full_legacy.md`.
+
+Conflict steps (must follow in order):
+1. Stop and read both sources.
+2. Decide which is newer and update the other.
+3. Record the decision in an ADR and the backlog card.
+
+## 3) Repo map (compact)
+
+- `AGENTS.md` (agent rules) + `agents/index.md` (routing).
+- `${paths.backlog_dir}/*.yml` (required work cards).
+- `/${paths.references_dir}/*` (API, data model, UI routes, status).
+- `/${paths.adrs_dir}/` (ADRs).
+- `/templates/` (card/spec templates).
+- `/src/` or project-specific source directory (application code).
+
+## 4) Non-negotiables (MUST)
+
+### 4.a — Universal MUST (apply to every project)
+
+- MUST treat `AGENTS.md` as authoritative for agent rules.
+- MUST invoke `codebase-architect` agent (via Task tool) whenever you need to understand codebase structure, existing patterns, or code architecture before planning or implementing changes; do not proceed with planning or implementation without first understanding the existing system through codebase-architect.
+- MUST NOT work on files/components already claimed by another agent; multiple agents allowed if working on independent areas.
+- MUST perform a mandatory clarity analysis before fixing any issue labeled `bug`; confirm that the issue description, proposed correct behavior, and edge cases are unambiguous, document any resolved doubts, and only start fix work once every zone of uncertainty is covered.
+- MUST mark missing info as UNKNOWN and ask the user; if blocked, set `BLOCKED` with a blocker.
+- MUST mark assumptions as ASSUMED with rationale; add an ADR if permanent (and `features.has_adrs: true`).
+- MUST NOT make forbidden assumptions: external provider swap, auth provider swap, DB structure change without data model update, external dependency without documentation, API contract change without API reference update.
+- MUST keep docs and code in sync; code change without doc update is invalid; doc update without code is incomplete.
+- MUST use commit format `[FEAT-XXX] Brief description` or adapt to your project's convention; keep commits small/traceable.
+- MUST NOT commit without updated docs or with failing lint/type checks. Full build is required only before opening a PR, not before every commit.
+- MUST pre-sync: `git fetch origin`, clean status, confirm branch; use `git pull --ff-only` unless approved.
+- MUST get owner approval before force push/reset/branch deletion; create a safety tag `backup/<YYYYMMDD>-<reason>`.
+- MUST NEVER push directly to `main`; all changes reach `main` via PR (release from `develop` or hotfix merge). Pre-push hook enforces this.
+- MUST push working branch and keep `main` merge owner-controlled; prune remote branches only when instructed.
+- MUST run testing gates before DONE: run tests (if exist), run build, and CI checks on PR; manual validation is REQUIRED for local mode and OPTIONAL for cloud mode.
+- MUST pass pre-commit hooks (linting, type checking, markdown lint, build); bypass (`--no-verify`) only for documented emergencies.
+- MUST use API versioning for breaking changes: create new version, deprecate old with appropriate headers, minimum sunset period; see project-specific API migration docs.
+- MUST use exact terminology from `agents/coding-standards.md` if it exists in your project, plus any terminology declared in `.baldart/overlays/<skill>.md`.
+
+### 4.b — Workflow MUST (only when the matching `features.*` flag is `true`)
+
+- **When `features.has_backlog: true`:**
+  - MUST pick one backlog card (TODO/READY), set `IN_PROGRESS`, and assign yourself before work.
+  - MUST ask the user which git strategy to use when creating a backlog card and record it in `git_strategy`; if the user requires cloud-agent execution, use a non-main feature branch.
+  - MUST keep backlog tasks/notes/status current and log decisions.
+  - MUST follow the `git_strategy` specified in the backlog card; if not specified, ask the user before starting work; delete merged branches when instructed.
+  - MUST use branch-per-card (`feat/<CARD-ID>-<slug>`, `codex/<CARD-ID>-<slug>`, or `claude/<CARD-ID>-<slug>`), branching from `develop` for features and from `main` for hotfixes only.
+  - MUST document every implementation or variation (backlog card/spec/docs update referencing the issue/feature) before merging.
+
+- **When the file `${paths.references_dir}/project-status.md` exists:**
+  - MUST update its Active Code Context before work; multiple agents allowed if working on independent areas.
+  - MUST follow handoff protocol in Active Code Context; receiver acknowledges and sets `IN_PROGRESS`.
+  - MUST keep it under 200 lines; archive detailed work logs to `${paths.references_dir}/work-history.md`.
+  - MUST limit Active Code Context to 1 current + 3 recent entries max; use one-line summaries (no file lists).
+  - MUST archive work entries older than 7 days to `work-history.md`.
+
+- **When `features.has_adrs: true`:**
+  - MUST create complete ADRs (Context, Decision, Rationale, Alternatives, Consequences; no TODO placeholders) for architectural decisions: provider changes, auth changes, DB schema changes, API contract changes, external dependencies, deployment targets, performance/scalability decisions, data model changes affecting multiple features.
+
+- **When the project ships a GitHub issue review convention** (declared in `.baldart/overlays/`):
+  - MUST comment on every GitHub issue when resolving it and apply the project's review label (e.g. `vibe review`) per the overlay's labelling rule.
+  - MUST create QA issues per test case (labels `qa` + area); when fixed add a fix summary, apply the review label, leave open; open QA issues are the source of truth.
+- MUST NOT add detailed file lists or multi-line work descriptions to project-status.md; use work-history.md instead.
+
+## 5) Guidelines (SHOULD)
+
+- SHOULD use Routing to load only relevant modules.
+- SHOULD update `${paths.references_dir}/project-status.md` when risks/status change.
+- SHOULD review for duplication or drift when updating docs.
+- SHOULD set `execution_mode: cloud` in backlog cards handled by cloud agents and claim file ownership using `claimed_paths`.
+
+## 5.1) Execution Modes
+
+- `local`: work on feature branches from `develop`; direct commits to `develop` allowed for trivial changes with owner approval; manual validation remains mandatory before DONE.
+- `cloud`: always use feature branch from `develop`, open PR to `develop`, and rely on CI-first validation; local dev server checks are advisory unless explicitly requested.
+- `hotfix`: branch from `main` for critical production fixes; merge to both `main` (deploy) and `develop` (sync); requires owner approval.
+
+## 6) Optional conventions (OPTIONAL)
+
+- OPTIONAL: None defined. Add project-specific conventions as needed.
+
+## 6.1) Deprecated Patterns (DO NOT USE)
+
+- Add project-specific deprecated patterns here as they emerge.
+- Example: Legacy authentication patterns, outdated API endpoints, deprecated libraries, etc.
+
+## 7) Routing (If you touch X, read Y)
+
+- **Documentation routing**: See `agents/index.md` for which docs to read/update when touching code.
+- **Agent invocation routing**: See `.claude/agents/REGISTRY.md` for which agent to invoke via Task tool (single source of truth for all agent capabilities, categories, and decision tree). When adding or updating agents, update REGISTRY.md.
+
+## 8) Workflow gates (tests/build/deploy)
+
+### Pre-commit checks (MUST — fast, ~30s)
+
+Before attempting any `git commit`, MUST run these checks on affected files and fix all errors:
+
+1. Lint check on changed source files — fix all lint errors.
+2. Type check (if applicable) — fix all type errors.
+3. Markdown lint on changed `.md` files (if .md files changed) — fix all errors.
+
+Only after all checks pass, proceed with `git add` and `git commit`.
+Do NOT run a full build before every commit — it kills agent velocity.
+Do NOT rely on pre-commit hooks to catch these — run them explicitly first to avoid failed commit retry cycles.
+
+Note: Use linting tools that scope to staged files only when possible; type checking may need to run on the whole project depending on your language/toolchain.
+
+### Pre-PR build check (MUST — before opening any PR)
+
+Before opening a pull request, MUST run:
+
+1. Full build — must pass with no errors.
+2. Full test suite — if tests exist, must pass.
+
+This is the only time a full build is required. Do not repeat this for every intermediate commit.
+
+### Manual testing protocol (MVP)
+
+1. Run test suite when tests exist.
+2. Run build command (must pass).
+3. Run project and manually test changed flows.
+4. Record results in backlog card notes.
+
+QA issue methodology (manual):
+- One GitHub issue per test case (atomic scope).
+- Labels: `qa` + one macro area (customize area labels for your project).
+- When fixed: add fix summary comment, apply `vibe review`, leave open.
+- If test passes: leave issue open with a short note.
+- If test fails: keep open with details and evidence.
+- Open QA issues are the source of truth for unresolved bugs.
+
+## 9) Token budget / truncation policy
+
+### File size thresholds
+
+| Doc Type | Max Lines | Action When Exceeded |
+|----------|-----------|---------------------|
+| Index files (index.md) | 200 | Split by domain |
+| Agent modules (agents/*.md) | 300 | Split into sub-modules |
+| Reference docs (${paths.references_dir}/*) | 400 | Split by topic |
+| API docs (${paths.references_dir}/api/*) | 800 | Split by endpoint group |
+| Specs/PRDs (${paths.references_dir}/specs/*, ${paths.prd_dir}/*) | 800 | Split into requirements + implementation |
+| project-status.md | 200 | Archive to work-history.md |
+
+### When context is truncated
+
+1. Re-read only the specific section needed (use offset/limit).
+2. Use index files (`api/index.md`, `ui/index.md`, `agents/index.md`) to navigate — never load all docs at once.
+3. Link over duplicate — one source of truth per fact.
+4. Prefer tables over prose for structured data.
+5. If a file exceeds its threshold by 50%+, create a backlog card to split it.
+
+### Loading priority
+
+When context budget is limited, load in this order:
+1. `AGENTS.md` (rules — always first)
+2. `agents/index.md` (routing)
+3. Relevant domain module only (not all modules)
+4. `${paths.references_dir}/project-status.md` (if status context needed)
+
+## 10) Change protocol (updating this file)
+
+1. Open/update a backlog card for doc changes.
+2. Update the relevant module(s) first.
+3. Update `${paths.references_dir}/project-status.md` if status or risks change.
+4. Add an ADR for architectural decisions.
+5. Review for duplication or drift.

package/framework/agents/api-contracts.md

@@ -0,0 +1,137 @@
+# API Contracts
+
+## Purpose
+
+Define API endpoint documentation standards and contract rules.
+
+## Scope
+
+**In**: API documentation format, versioning, breaking changes, error responses.
+**Out**: Specific endpoint implementations (see ${paths.references_dir}/api/).
+
+## Do
+
+- Document all API endpoints in ${paths.references_dir}/api/
+- Follow consistent request/response format
+- Version APIs appropriately
+- Document error responses
+
+## Do Not
+
+- Make breaking changes without versioning
+- Skip documenting endpoints
+- Change contracts without updating docs
+
+## API Documentation Format
+
+Each endpoint should document:
+
+```markdown
+### [METHOD] /api/[version]/[resource]
+
+**Purpose**: [What this endpoint does]
+
+**Auth**: [Required authentication - e.g., Bearer token, API key, none]
+
+**Request**:
+- **Headers**: [Required headers]
+- **Path Params**: [URL parameters]
+- **Query Params**: [Query string parameters]
+- **Body**: [Request body schema]
+
+**Response**:
+- **Success (200)**: [Success response schema]
+- **Error (4xx/5xx)**: [Error response schema]
+
+**Example Request**:
+\`\`\`json
+{
+  "field": "value"
+}
+\`\`\`
+
+**Example Response**:
+\`\`\`json
+{
+  "data": "value",
+  "message": "Success"
+}
+\`\`\`
+
+**Business Rules**:
+- [Rule 1]
+- [Rule 2]
+
+**Error Codes**:
+- `ERROR_CODE_1`: Description
+- `ERROR_CODE_2`: Description
+```
+
+## Versioning Strategy
+
+- Use semantic versioning for API versions (v1, v2, etc.)
+- Maintain backwards compatibility within major versions
+- Deprecate old versions with appropriate sunset periods
+- Document version differences
+
+## Breaking vs Non-Breaking Changes
+
+**Non-Breaking** (can be added without version bump):
+
+- Adding new optional fields to requests
+- Adding new fields to responses
+- Adding new endpoints
+- Adding new optional query parameters
+
+**Breaking** (require version bump):
+
+- Removing fields from responses
+- Changing field types
+- Making optional fields required
+- Removing endpoints
+- Changing authentication requirements
+- Changing error response format
+
+## Error Response Format
+
+Define a consistent error response format:
+
+```json
+{
+  "error": {
+    "code": "ERROR_CODE",
+    "message": "Human readable message",
+    "details": {}
+  }
+}
+```
+
+## API Conventions
+
+- [HTTP method conventions]
+- [Resource naming conventions]
+- [Query parameter conventions]
+- [Pagination conventions]
+- [Filtering conventions]
+- [Sorting conventions]
+
+## Authentication
+
+- [Authentication method - Bearer, API Key, etc.]
+- [Token format]
+- [Token expiration]
+- [Refresh token flow if applicable]
+
+## Rate Limiting
+
+- [Rate limit rules if applicable]
+- [Rate limit headers]
+- [Handling rate limit errors]
+
+## Deprecation Policy
+
+1. Announce deprecation with timeline
+2. Add deprecation headers to responses
+3. Update documentation with migration guide
+4. Maintain deprecated version for sunset period
+5. Remove after sunset period expires

package/framework/agents/architecture.md

@@ -0,0 +1,145 @@
+# Architecture
+
+## Purpose
+
+Summarize system architecture, tech stack, and core flows.
+
+## Scope
+
+**In**: Tech stack, architecture patterns, authentication flows, key principles.
+**Out**: API details (see ${paths.references_dir}/api/index.md), data model (see ${paths.references_dir}/data-model.md).
+
+## Do
+
+- Align changes with the documented patterns and principles.
+- Update this file when architecture or tech stack changes.
+
+## Do Not
+
+- Change providers or architecture without an ADR.
+
+## Content
+
+# Tech Stack
+
+## Frontend
+
+- **Framework**: [Your framework here - e.g., React, Next.js, Vue, Angular]
+- **Language**: [Your language here - e.g., TypeScript, JavaScript]
+- **Styling**: [Your styling approach - e.g., Tailwind CSS, CSS Modules, styled-components]
+- **UI Approach**: [Your UI approach - e.g., mobile-first, responsive, component library]
+- **State**: [Your state management - e.g., Redux, Zustand, Context API, none]
+- **Session**: [Your session storage approach - e.g., localStorage, sessionStorage, cookies]
+
+## Backend
+
+- **Runtime**: [Your runtime - e.g., Node.js, Python, Go, Rust]
+- **Database**: [Your database - e.g., PostgreSQL, MongoDB, Firebase, Supabase]
+- **Storage**: [Your storage solution - e.g., S3, local filesystem, none]
+- **Authentication**: [Your auth approach - e.g., JWT, OAuth, Firebase Auth, Supabase Auth, custom]
+
+## Build/Deploy
+
+- **Build**: [Your build tool - e.g., Vite, Webpack, Next.js, esbuild]
+- **Linting**: [Your linter - e.g., ESLint, Biome, RuboCop, pylint]
+- **Package Manager**: [Your package manager - e.g., npm, pnpm, yarn, pip, cargo]
+- **Testing**: [Your test framework - e.g., Jest, Vitest, pytest, cargo test]
+
+## External Dependencies
+
+- List key external dependencies here
+- Include purpose for each dependency
+- Update when adding or removing major dependencies
+
+---
+
+# Architecture
+
+## Pattern
+
+- **Frontend**: [Your frontend architecture pattern]
+- **Backend**: [Your backend architecture pattern]
+- **Auth**: [Your authentication flow]
+- **Data flow**: [Your data flow pattern - e.g., Client → API → Database → Response]
+
+## Key Principles
+
+- List your project's key architectural principles here
+- Include design patterns you follow
+- Document constraints and trade-offs
+- Examples:
+  - Mobile-first UI
+  - RESTful API design
+  - No real-time subscriptions
+  - Immutable data patterns
+  - Specific performance targets
+
+## Authentication Flow
+
+### User Type 1 (e.g., End Users)
+
+1. [Step 1 of authentication]
+2. [Step 2 of authentication]
+3. [Step 3 of authentication]
+4. [Session storage/management]
+
+### User Type 2 (e.g., Admin Users)
+
+1. [Step 1 of authentication]
+2. [Step 2 of authentication]
+3. [Step 3 of authentication]
+4. [Session storage/management]
+
+## Core Business Flows
+
+### Flow 1: [Name of key flow]
+
+1. [Step 1]
+2. [Step 2]
+3. [Step 3]
+4. [Validation/error handling]
+5. [Side effects/notifications]
+6. [Return/response]
+
+### Flow 2: [Name of another key flow]
+
+1. [Step 1]
+2. [Step 2]
+3. [Step 3]
+
+---
+
+## Deployment Architecture
+
+- **Environment**: [Development/Staging/Production setup]
+- **Hosting**: [Your hosting solution - e.g., Vercel, AWS, GCP, self-hosted]
+- **CI/CD**: [Your CI/CD pipeline - e.g., GitHub Actions, CircleCI, Jenkins]
+- **Monitoring**: [Your monitoring solution - e.g., Sentry, Datadog, none]
+
+---
+
+## Security Considerations
+
+- [List key security measures]
+- [Authentication/authorization approach]
+- [Data encryption]
+- [API rate limiting]
+- [Input validation]
+
+---
+
+## Performance Targets
+
+- [Response time targets]
+- [Throughput targets]
+- [Scalability considerations]
+- [Caching strategy]
+
+---
+
+## Known Limitations
+
+- [Document known architectural limitations]
+- [Technical debt]
+- [MVP vs Production trade-offs]
+- [Areas requiring future improvement]

package/framework/agents/coding-standards.md

@@ -0,0 +1,148 @@
+# Coding Standards
+
+## Purpose
+
+Ensure consistent terminology and naming across code and docs.
+
+## Scope
+
+**In**: Terminology rules for UI, code, docs, and commit messages.
+**Out**: Formatting or lint rules (handled by tooling).
+
+## Do
+
+- Use the exact terms below in code, docs, and issues.
+
+## Do Not
+
+- Substitute synonyms for defined terms.
+
+## Terminology
+
+Define project-specific terminology here to ensure consistency across codebase:
+
+| Correct | Avoid |
+|---|---|
+| [Term 1] | [Synonym 1], [Synonym 2] |
+| [Term 2] | [Synonym 1], [Synonym 2] |
+| [Term 3] | [Synonym 1], [Synonym 2] |
+
+### Examples of Terminology to Define
+
+- **User Types**: End user, admin, moderator, customer, etc.
+- **Core Entities**: Product, order, transaction, item, etc.
+- **Actions**: Create, add, register, signup, etc.
+- **UI Elements**: Modal, dialog, popup, drawer, etc.
+- **Status Values**: Active, enabled, live, published, etc.
+
+## Code Conventions
+
+### Naming Conventions
+
+- **Files**: [Your convention - e.g., kebab-case, camelCase, PascalCase]
+- **Functions**: [Your convention - e.g., camelCase, snake_case]
+- **Components**: [Your convention - e.g., PascalCase]
+- **Constants**: [Your convention - e.g., SCREAMING_SNAKE_CASE]
+- **Variables**: [Your convention - e.g., camelCase, snake_case]
+
+### Project-Specific Patterns
+
+Document any project-specific coding patterns here:
+
+#### Example: File Organization
+
+```
+src/
+  features/
+    [feature-name]/
+      components/
+      hooks/
+      utils/
+      types.ts
+      index.ts
+```
+
+#### Example: Import Order
+
+1. External dependencies
+2. Internal utilities
+3. Components
+4. Types
+5. Styles
+
+#### Example: Error Handling
+
+```typescript
+// Preferred pattern
+try {
+  // operation
+} catch (error) {
+  // handle error
+}
+
+// Avoid pattern
+if (error) {
+  // handle error
+}
+```
+
+## Commit Message Format
+
+- **Format**: `[TYPE-XXX] Brief description` or adapt to your project convention
+- **Types**: feat, fix, docs, refactor, test, chore
+- **Examples**:
+  - `[FEAT-123] Add user authentication`
+  - `[FIX-456] Resolve login redirect issue`
+  - `[DOCS-789] Update API documentation`
+
+## Documentation Standards
+
+### Code Comments
+
+- Comment **why**, not **what**
+- Use JSDoc/docstrings for public APIs
+- Avoid obvious comments
+- Update comments when code changes
+
+### README Requirements
+
+- Installation instructions
+- Configuration steps
+- Usage examples
+- Contributing guidelines
+- License information
+
+## Type Safety (if applicable)
+
+- [Your type safety requirements]
+- [Strictness level]
+- [Type annotation requirements]
+- [Any/unknown usage policy]
+
+## Testing Standards
+
+- [Test coverage requirements]
+- [Test naming conventions]
+- [Test file organization]
+- [Mocking guidelines]
+
+## Accessibility Standards (if applicable)
+
+- [ARIA label requirements]
+- [Keyboard navigation requirements]
+- [Screen reader compatibility]
+- [Color contrast requirements]
+
+## Performance Standards (if applicable)
+
+- [Bundle size limits]
+- [Image optimization requirements]
+- [Lazy loading guidelines]
+- [Caching strategies]
+
+## Security Standards
+
+- [Input validation requirements]
+- [Authentication patterns]
+- [Data sanitization rules]
+- [Secrets management]