nitm-ai-dev-toolkit 3.0.15

package/src/monorepo/.claude/rules/server-client-separation.md

@@ -0,0 +1,17 @@
+---
+paths:
+  - "src/**"
+  - "apps/**"
+  - "packages/**"
+description: "Server and client code separation rules."
+---
+
+# Server-Client Separation
+
+Follow the rules defined in [.claude/rules-snippets/server-client-separation.md](../rules-snippets/server-client-separation.md).
+
+Key points:
+- Never import server-only code in client components.
+- Use API endpoints to expose server functionality to clients.
+- Create shared types for cross-boundary use.
+- Mark server-only modules clearly (e.g., `.server.{{LANGUAGE_EXTENSION}}`).

package/src/monorepo/.claude/rules/subagent-workflow.md

@@ -0,0 +1,14 @@
+---
+applyTo: "**/*"
+description: "Subagent workflow and orchestration patterns."
+---
+
+# Subagent Workflow
+
+Follow the rules defined in [.claude/rules-snippets/subagent-workflow.md](../rules-snippets/subagent-workflow.md).
+
+Key points:
+- Use orchestrator-first flow for tasks involving 2+ of research, planning, implementation, testing, or review.
+- Default to coordinator agents (Feature Builder or TDD) as entry points for non-trivial work.
+- Match task domain to the right specialist before defaulting to Implementer.
+- Always run Reviewer after implementation, before marking work complete.

package/src/monorepo/.claude/rules/testing-quality.md

@@ -0,0 +1,19 @@
+---
+paths:
+  - "**/*.{test,spec}.*"
+  - "tests/**"
+  - "__tests__/**"
+  - "apps/**/tests/**"
+  - "packages/**/tests/**"
+description: "Testing standards and quality assurance."
+---
+
+# Testing Quality
+
+Follow the rules defined in [.claude/rules-snippets/testing-quality.md](../rules-snippets/testing-quality.md).
+
+Key points:
+- Ensure lint, test, and build pass before committing.
+- Use {{TEST_FRAMEWORK}} for unit/component tests and {{E2E_FRAMEWORK}} for end-to-end tests.
+- Place tests alongside implementation files or in `tests/` directory.
+- Aim for meaningful test coverage of business logic.

package/src/monorepo/.claude/rules/testing.md

@@ -0,0 +1,16 @@
+---
+applyTo:
+  - "**/*.{test,spec}.*"
+  - "tests/**"
+  - "__tests__/**"
+description: "Testing standards, commands, and conventions."
+---
+
+# Testing Standards
+
+Follow the rules defined in [.claude/rules-snippets/testing.md](../rules-snippets/testing.md).
+
+Key points:
+- Unit tests: `{{TEST_FILE_PATTERN}}`, integration tests: `{{INTEGRATION_TEST_PATTERN}}`, E2E tests: `{{E2E_TEST_PATTERN}}`.
+- Minimum coverage: {{COVERAGE_THRESHOLD}}.
+- New features require tests before merging.

package/src/monorepo/.claude/rules/ui-accessibility.md

@@ -0,0 +1,18 @@
+---
+paths:
+  - "src/components/**"
+  - "apps/**/components/**"
+  - "packages/**/components/**"
+  - "**/*.{vue,tsx,jsx,css,scss}"
+description: "UI accessibility and responsive design standards."
+---
+
+# UI Accessibility
+
+Follow the rules defined in [.claude/rules-snippets/ui-accessibility.md](../rules-snippets/ui-accessibility.md).
+
+Key points:
+- Develop with a mobile-first approach.
+- Adhere to WCAG 2.1 AA accessibility standards.
+- Use semantic HTML elements and ensure keyboard navigation.
+- Use loading states during async operations.

package/src/monorepo/.claude/rules/version-control.md

@@ -0,0 +1,14 @@
+---
+applyTo: "**/*"
+description: "Version control and commit conventions."
+---
+
+# Version Control
+
+Follow the rules defined in [.claude/rules-snippets/version-control.md](../rules-snippets/version-control.md).
+
+Key points:
+- Use conventional commit format: `<type>(<scope>): <description>`.
+- Types: feat, fix, docs, refactor, test, chore, style, perf.
+- Include ticket reference when applicable.
+- Follow the PR template for pull requests.

package/src/monorepo/.claude/rules/what-to-avoid.md

@@ -0,0 +1,14 @@
+---
+applyTo: "**/*"
+description: "Anti-patterns and things to avoid."
+---
+
+# What to Avoid
+
+Follow the rules defined in [.claude/rules-snippets/what-to-avoid.md](../rules-snippets/what-to-avoid.md).
+
+Key points:
+- No deprecated {{FRAMEWORK}} features or global CSS outside {{STYLING}} configuration.
+- No direct DOM manipulation; use framework reactivity.
+- No custom solutions for problems solved by core libraries.
+- No mixing server and client code inappropriately.

package/src/monorepo/.claude/rules-snippets/agent-conduct.md

@@ -0,0 +1,51 @@
+# Agent Conduct & Interaction Rules
+
+## ⚠️ CRITICAL: Orchestration Checkpoint First
+
+**BEFORE responding to ANY request with multiple steps (research + planning + implementation + testing + review):**
+
+- Read the orchestration checkpoint in [AGENTS.md](../../AGENTS.md#-critical-orchestration-checkpoint-read-first) and [subagent-workflow.md](./subagent-workflow.md#-before-starting-orchestration-checkpoint)
+- Determine if this task requires a coordinator agent (Feature Builder, TDD) or can be single-agent work
+- If multi-step work, document why you're using orchestrator-first in your response before proceeding
+
+This applies to ANY task that involves 2+ of: research, planning, implementation, testing, validation, code review.
+
+---
+
+## Clarification & Assumption Handling
+
+**CRITICAL**: Before making assumptions or proceeding with ambiguous requirements, agents MUST proactively ask the user for clarification. This applies to:
+
+- **Ambiguous requirements**: If a task description is vague, incomplete, or could be interpreted multiple ways, ask the user to clarify before proceeding.
+- **Architecture decisions**: When multiple valid approaches exist (e.g., adding a new service vs. extending an existing one), present options and ask for the user's preference.
+- **Data model changes**: Before adding/modifying database columns, relationships, or entities, confirm the intended schema with the user.
+- **Breaking changes**: If an implementation could break existing functionality, API contracts, or database compatibility, flag it and ask before proceeding.
+- **Scope uncertainty**: If unsure whether a feature should be minimal (MVP) or comprehensive, ask about the desired scope.
+- **External dependencies**: When a task requires secrets, third-party services, or infrastructure not yet configured, ask the user before assuming.
+- **Domain-specific decisions**: Sensitive UX choices or domain-specific behavior should be confirmed with the user first.
+
+## How to Ask for Clarification
+
+- Be specific about what is unclear and why it matters
+- Offer 2-3 concrete options when possible (with a recommended default)
+- Explain the trade-offs of each option briefly
+- If there is a clearly best practice, recommend it but still confirm
+
+### Example
+
+> "This endpoint could return paginated results or the full list. Given the expected data volume, I'd recommend pagination with a default page size of 20. Should I proceed with that approach, or do you prefer returning all results?"
+
+## Decision Documentation
+
+When a clarification is resolved:
+
+1. **Record the decision** in a code comment or relevant documentation
+2. **Reference the rationale** so future agents/developers understand why
+3. **Update specs/plans** if the decision changes the original scope
+
+## Guardrails
+
+- **Never silently change** database schemas, API contracts, or auth flows without confirmation
+- **Never assume scope** — if a task says "add search," ask whether it means basic text search, full-text search, or filter/facet search
+- **Never skip tests** for assumed-correct behavior — confirm expectations first
+- **Prefer reversible changes** when acting without full clarity

package/src/monorepo/.claude/rules-snippets/api-server.md

@@ -0,0 +1,5 @@
+- {{API_ROUTE_PATTERN}}
+- Validate all input data before processing.
+- Return consistent response formats.
+- Use proper HTTP status codes.
+- Document API endpoints in {{API_DOCS_LOCATION}}.

package/src/monorepo/.claude/rules-snippets/coding-standards.md

@@ -0,0 +1,45 @@
+# Coding Standards
+
+## Primary Pattern: {{PRIMARY_PATTERN_NAME}}
+
+```{{FILE_EXTENSION}}
+{{PRIMARY_PATTERN_EXAMPLE}}
+```
+
+**Rules:**
+
+- {{CODING_RULE_1}}
+- {{CODING_RULE_2}}
+- {{CODING_RULE_3}}
+
+## Data Access Pattern
+
+```{{FILE_EXTENSION}}
+{{DATA_ACCESS_PATTERN}}
+```
+
+## API / Route Pattern
+
+```{{FILE_EXTENSION}}
+{{API_PATTERN}}
+```
+
+## Naming Conventions
+
+- Files: {{FILE_NAMING_CONVENTION}}
+- Components: {{COMPONENT_NAMING_CONVENTION}}
+- Functions: {{FUNCTION_NAMING_CONVENTION}}
+- Variables: {{VARIABLE_NAMING_CONVENTION}}
+
+## Code Quality
+
+- Follow {{FRAMEWORK}} and {{LANGUAGE}} best practices
+- Run linting before committing: `{{LINT_COMMAND}}`
+- Format code consistently: `{{FORMAT_COMMAND}}`
+
+## SRP and reuse-first principle
+
+- **Before implementing new functionality, review existing patterns** in `{{COMPOSABLES_PATH}}`, `{{UTILS_PATH}}`, and `{{HELPERS_PATH}}` for capabilities that already solve the problem.
+- **Prefer extending existing utilities** over creating new ones or duplicating logic inline — a new solution is only warranted when the existing one genuinely cannot accommodate the use case.
+- **Never duplicate state or behavior** that an existing utility already manages (e.g., loading flags, error state, async wrappers). Inline duplication violates SRP and makes behavior inconsistent across the codebase.
+- When in doubt, extend the existing pattern and keep consumers (components, controllers, handlers) thin.

package/src/monorepo/.claude/rules-snippets/component-structure.md

@@ -0,0 +1,6 @@
+- {{COMPONENT_STRUCTURE_RULE}}
+- Follow the {{COMPONENT_PATTERN}} pattern for all components.
+- Use clear and descriptive naming for props, events, and methods.
+- Keep logic within components focused and manageable.
+- Add code comments for complex logic or non-obvious implementations.
+- Use bracketed identifiers for logs: `[ComponentName]: message`.

package/src/monorepo/.claude/rules-snippets/core-libraries.md

@@ -0,0 +1,6 @@
+# Core Libraries
+
+- Use {{UTILITY_LIBRARY}} for common utilities.
+- Use {{STATE_MANAGEMENT}} for state management.
+- Use {{STYLING}} for styling; prefer utility classes over custom CSS.
+- Use {{UI_LIBRARY}} for UI components; check existing components before creating new ones.

package/src/monorepo/.claude/rules-snippets/deployment.md

@@ -0,0 +1,41 @@
+## Apps
+
+| App              | Platform                  | Command                    |
+| ---------------- | ------------------------- | -------------------------- |
+| `{{APP_NAME_1}}` | {{APP_1_DEPLOY_PLATFORM}} | `{{APP_1_DEPLOY_COMMAND}}` |
+| `{{APP_NAME_2}}` | {{APP_2_DEPLOY_PLATFORM}} | `{{APP_2_DEPLOY_COMMAND}}` |
+
+## Environment Variables
+
+### Root Level
+
+```bash
+# .env (shared)
+{{ENVIRONMENT}}={{ENVIRONMENT_VALUE}}
+```
+
+### Per-App
+
+```bash
+# {{APP_DIR}}/{{APP_NAME_1}}/.env.local
+{{APP_1_ENV_EXAMPLE}}
+
+# {{APP_DIR}}/{{APP_NAME_2}}/.env.local
+{{APP_2_ENV_EXAMPLE}}
+```
+
+## CI/CD
+
+```yaml
+# .github/workflows/ci.yml (or equivalent)
+{ { CI_WORKFLOW_EXAMPLE } }
+```
+
+## Pre-Deployment Checklist
+
+- [ ] All tests pass across workspace
+- [ ] Linting passes
+- [ ] Build completes for all affected apps
+- [ ] Environment variables configured per app
+- [ ] Database migrations applied (if applicable)
+- [ ] Shared package changes tested in all consuming apps

package/src/monorepo/.claude/rules-snippets/documentation.md

@@ -0,0 +1,210 @@
+## Overview
+
+This monorepo uses a **distributed documentation strategy** where app-specific documentation lives with each app, and only monorepo-wide concerns are documented at the root level.
+
+## Documentation Location Rules
+
+### CRITICAL: App-Specific vs Root Documentation
+
+**App-specific documentation** must live in respective app folders:
+
+- **{{APP_1}} Features** → `apps/{{APP_1}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/`
+- **{{APP_2}} Features** → `apps/{{APP_2}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/`
+- **{{APP_1}} Fixes** → `apps/{{APP_1}}/docs/fixes/`
+- **{{APP_2}} Fixes** → `apps/{{APP_2}}/docs/fixes/`
+- **Shared Package Features** → `packages/{{PACKAGE_NAME}}/docs/features/`
+- **Shared Package Fixes** → `packages/{{PACKAGE_NAME}}/docs/fixes/`
+
+**Root `docs/` folder** is ONLY for monorepo-wide documentation:
+
+- Architecture decisions affecting multiple apps (`docs/architecture/`)
+- Deployment pipelines and infrastructure
+- Cross-app integration patterns (`docs/integration/`)
+- General project overview and getting started
+- Monorepo-wide tooling and configuration
+- Developer guides and onboarding (`docs/guides/`)
+- Project constitution (`docs/constitution.md`)
+
+### Decision Tree: Where to Document?
+
+```
+Is this change specific to ONE app or package?
+├── YES → Document in `apps/{{APP_NAME}}/docs/` or `packages/{package}/docs/`
+└── NO → Does it affect multiple apps or the monorepo structure?
+    ├── YES → Document in root `docs/`
+    └── NO → You might be documenting the wrong thing
+```
+
+## Per-App Documentation Obligations
+
+These rules apply to **every app** in `apps/*` and **every package** in `packages/*`. The trigger for writing docs is a code change in that app or package, not just feature-level work.
+
+| App / Package       | Change type                                                        | Required doc action                                                                                        |
+| ------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
+| `apps/{{APP_1}}`    | New or modified API route / controller                             | Update `docs/api/` endpoint spec **and** add/update the corresponding page in `apps/{{DOCS_APP}}/content/` |
+| `apps/{{APP_1}}`    | New module / service                                               | Add to feature spec (`docs/features/`) and note architectural choices                                      |
+| `apps/{{APP_1}}`    | Breaking change (renamed/removed endpoint, changed response shape) | Update `docs/api/`, `apps/{{DOCS_APP}}/content/`, **and** `CHANGELOG.md`                                   |
+| `apps/{{APP_2}}`    | New page / UI feature                                              | Update feature spec (`docs/features/`) and add/update page in `apps/{{DOCS_APP}}/content/` if user-facing  |
+| `apps/{{APP_2}}`    | New route handler or API route                                     | Update relevant feature spec                                                                               |
+| `apps/{{DOCS_APP}}` | Content-only edits (MDX/MDC, navigation config)                    | No extra docs required — changes here **are** the documentation update                                     |
+| `packages/*`        | New or changed public API                                          | Update `docs/api/` and add/update the relevant page in `apps/{{DOCS_APP}}/content/`                        |
+
+> **Rule of thumb:** If you added or changed a controller, an API route handler, or any function that is callable from another app or external client, you must update both `docs/api/` **and** `apps/{{DOCS_APP}}/content/` before committing.
+
+## Docs App (`apps/{{DOCS_APP}}`) Sync Requirements
+
+If the monorepo includes a documentation app (e.g., Docus, Nuxt Content, Docusaurus, Nextra, Starlight), the site content **must be updated as part of every commit that changes user-facing behavior**.
+
+### When to Update the Docs App
+
+| Trigger                       | Action in `apps/{{DOCS_APP}}/content/`           |
+| ----------------------------- | ------------------------------------------------ |
+| New feature shipped           | Create or update the relevant documentation page |
+| API endpoint added or changed | Update the API reference page                    |
+| Breaking change               | Add migration guide or update affected pages     |
+| Bug fix that changes behavior | Update any page that described the old behavior  |
+| New shared package public API | Add or update the package reference page         |
+| UI component added            | Add usage examples page if user-facing           |
+| Configuration change          | Update setup / configuration pages               |
+
+### What Does NOT Require a Docs App Update
+
+- Internal refactors with no behavior change
+- CI/CD pipeline changes (unless they affect developer setup)
+- Test-only changes
+- Dependency updates with no API changes
+- Content edits within `apps/{{DOCS_APP}}` itself (these are the docs)
+
+## App-Specific Documentation
+
+### Feature Documentation Structure
+
+Each app maintains its own feature documentation:
+
+**Location:** `apps/{{APP_NAME}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/`
+
+**Required Files:**
+
+```
+apps/{{APP_1}}/docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/
+├── spec.md       # Functional specification
+├── plan.md       # Implementation plan
+└── [optional]    # Code examples, component diagrams
+```
+
+### Fix & Bug Documentation
+
+**App-specific fixes follow a tiered structure:**
+
+#### Decision Tree
+
+**Before creating any fix documentation, ask:**
+
+1. **Is this a complex fix?** (multi-file, architectural changes, affects multiple features)
+   - ✅ YES → Create folder `apps/{{APP_NAME}}/docs/fixes/{{ISSUE_ID}}-{{FIX_NAME}}/` with `spec.md` + `plan.md`
+   - ❌ NO → Add entry to `apps/{{APP_NAME}}/docs/fixes/{{YYYY-MM}}.md` (monthly log)
+
+2. **Does the monthly log for this month exist?**
+   - ❌ NO → Create it first using the template below
+   - ✅ YES → Add your fix as a new section
+
+**⚠️ CRITICAL: Do NOT create individual `.md` files for simple fixes!**
+
+## Root-Level Documentation
+
+### When to Use Root `docs/`
+
+Create root-level documentation for:
+
+1. **Architecture Decisions** affecting multiple apps
+2. **Deployment & Infrastructure** (CI/CD, hosting, environments)
+3. **Cross-App Integration** patterns and contracts
+4. **Monorepo Tooling** (Turborepo, workspace management)
+5. **Getting Started** guides for new developers
+6. **Project Overview** and high-level architecture
+
+### Architecture Decision Records (ADRs)
+
+**Location:** `docs/architecture/{{NNNN}}-{{DECISION_TITLE}}.md`
+
+**When to Create Root ADRs:**
+
+- Choosing monorepo structure
+- Selecting build system (Turborepo, Nx, etc.)
+- API gateway vs direct app communication
+- Shared package strategy
+- Cross-app authentication approach
+- Deployment platform decisions
+
+## Changelog Management
+
+### App-Specific Changelogs
+
+Each app maintains its own `CHANGELOG.md`:
+
+**Location:** `apps/{{APP_NAME}}/CHANGELOG.md`
+
+### Root Changelog
+
+**Location:** `CHANGELOG.md` (root)
+
+Tracks monorepo-wide changes.
+
+## Pre-Commit Documentation Gate
+
+**⚠️ MANDATORY: Documentation MUST be written or updated BEFORE committing code. This is a hard requirement — no commit should land without the corresponding docs entry.**
+
+### Pre-Commit Checklist
+
+Before running `git commit`, verify ALL items that apply to your change:
+
+**All changes:**
+
+- [ ] **Features**: `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/spec.md` exists and reflects the current implementation
+- [ ] **Features**: `docs/features/{{ISSUE_ID}}-{{FEATURE_NAME}}/plan.md` is updated if scope changed
+- [ ] **Fixes**: Entry added to `apps/{{APP_NAME}}/docs/fixes/{{YYYY-MM}}.md` (or complex fix folder created)
+- [ ] **Breaking changes**: `CHANGELOG.md` updated
+- [ ] **Architectural decisions**: ADR created in `docs/architecture/` if a significant choice was made
+
+**App changes (API routes, controllers, services):**
+
+- [ ] New or modified endpoints documented in `docs/api/`
+- [ ] Corresponding `apps/{{DOCS_APP}}/content/` page created or updated
+- [ ] Removed or renamed endpoints noted as breaking changes
+- [ ] New modules/services referenced in the relevant feature spec
+
+**Frontend app changes (pages, UI features):**
+
+- [ ] New route handlers documented in the relevant feature spec under `docs/features/`
+- [ ] Any public-facing features have a corresponding `apps/{{DOCS_APP}}/content/` page created or updated
+
+**`packages/*` changes:**
+
+- [ ] New or changed public exports documented in `docs/api/` or the relevant feature spec
+- [ ] `apps/{{DOCS_APP}}/content/` updated if the change is developer-facing
+
+If any applicable item is missing, **write the documentation first, then commit**.
+
+## Best Practices
+
+### Do
+
+- ✅ Keep app-specific docs with app code
+- ✅ Use root docs only for cross-cutting concerns
+- ✅ Link between related docs across apps
+- ✅ Maintain separate changelogs per app
+- ✅ Document API contracts explicitly
+- ✅ Update all affected app docs for shared changes
+- ✅ Update `apps/{{DOCS_APP}}/content/` with every user-facing change
+- ✅ Keep docs app navigation in sync when adding new pages
+
+### Don't
+
+- ❌ Put app-specific features in root docs
+- ❌ Duplicate documentation across apps
+- ❌ Create individual fix files for simple bugs
+- ❌ Forget to update API contract docs
+- ❌ Mix app-specific and monorepo concerns
+- ❌ Let cross-app integration docs become stale
+- ❌ Commit feature code without updating the docs app
+- ❌ Duplicate internal specs into the docs app verbatim — distill user-facing content instead

package/src/monorepo/.claude/rules-snippets/environment-tooling.md

@@ -0,0 +1,4 @@
+- Tailor commands to the user's OS and shell.
+- Use `{{PACKAGE_MANAGER}}` for package management.
+- {{TOOLING_RULE_1}}
+- {{TOOLING_RULE_2}}

package/src/monorepo/.claude/rules-snippets/logging-comments.md

@@ -0,0 +1,4 @@
+- Comment complex logic and non-obvious implementations.
+- Use bracketed identifiers for logs: `[ModuleName]: message`.
+- Use appropriate log levels: error, warn, info, debug.
+- Remove debug logs before committing to main branch.

package/src/monorepo/.claude/rules-snippets/logging.md

@@ -0,0 +1,107 @@
+# Monorepo Logging Standards
+
+## Format
+
+Always include app or package context:
+
+```{{FILE_EXTENSION}}
+// App logs
+console.log('[App:{{APP_1}}] [Source]: Message | details');
+
+// Package logs
+console.error('[Pkg:{{PACKAGE_1}}] [Service]: Error | context');
+
+// Bad - no context
+console.log('message');
+```
+
+## Log Levels
+
+- **error**: Critical failures (database, API, cross-app calls)
+- **warn**: Non-critical issues (deprecations, version mismatches)
+- **info**: Significant events (startup, cross-app communication)
+- **debug**: Diagnostic details (cross-package calls, state)
+
+## Monorepo Best Practices
+
+✅ Always prefix with `[App:name]` or `[Pkg:name]`
+✅ Use correlation IDs for cross-app requests
+✅ Log all inter-app communication
+✅ Include package versions on init
+✅ Centralize logging in shared package
+✅ Sanitize sensitive data
+
+❌ Don't log without app/package context
+❌ Don't mix log formats across apps
+❌ Don't log passwords/tokens
+❌ Don't log in tight loops
+
+## Cross-App Tracing
+
+```javascript
+// Generate correlation ID in {{APP_1}}
+const correlationId = generateId();
+
+// Pass to {{APP_2}}
+await fetch("{{APP_2}}/api", {
+	headers: { "X-Correlation-ID": correlationId },
+});
+
+// Log everywhere
+console.info("[App:{{APP_1}}]: Request | correlationId:", correlationId);
+console.info("[Pkg:{{PACKAGE_1}}]: Processing | correlationId:", correlationId);
+console.info("[App:{{APP_2}}]: Received | correlationId:", correlationId);
+```
+
+## Shared Logger
+
+Create `packages/{{PACKAGE_LOGGING}}`:
+
+```typescript
+export const createLogger = (appOrPackageName: string) => ({
+	error: (source, operation, error, context) => {
+		const prefix = appOrPackageName.startsWith("@")
+			? `[Pkg:${appOrPackageName}]`
+			: `[App:${appOrPackageName}]`;
+		console.error(`${prefix} [${source}] [${operation}]: ${error.message}`, {
+			error,
+			...context,
+		});
+	},
+	// ... other methods
+});
+
+// Usage
+import { createLogger } from "@{{PROJECT_NAME}}/{{PACKAGE_LOGGING}}";
+const logger = createLogger("{{APP_1}}");
+logger.error("Service", "operation", error, { userId });
+```
+
+## Sensitive Data
+
+Never log:
+
+- Passwords/API keys
+- Tokens/certificates
+- Credit card/SSN
+- Session cookies
+- Internal credentials
+
+Sanitize:
+
+```javascript
+const sanitized = {
+	...data,
+	password: undefined,
+	cardNumber: "****" + data.cardNumber?.slice(-4),
+};
+console.log("[App:{{APP_1}}] [Service]: Data", sanitized);
+```
+
+## Production
+
+- Use shared logging package
+- Add correlation IDs
+- Per-app log levels
+- Centralize with tags (Datadog, Sentry)
+- Track cross-app metrics