[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M715817B1F59DYB3DPGPWWY2":3,"skill-same:01M715817B1F59DYB3DPGPWWY2":60},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":14,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":59},"01M715817B1F59DYB3DPGPWWY2","architecture-decision-records",null,"Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.","sapsapshen\u002Fai-memory-router","sapsapshen","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F20347959?v=4","01M6XDQEF1DP50DKF37H81J3J5","shenmian","01M6XDQEJPE41Y3DT2763X8ZJN",0,"MIT","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcursor\u002Farchitecture-decision-records\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"architecture","architecture decision records","decision","records","architecture decision","technical","capture","decisions","context","community","patterns","for","unknown","rationale","2026","2026-11-10 10:12:30",false,"---\nname: architecture-decision-records\ndescription: \"Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.\"\nrisk: unknown\nsource: community\ndate_added: \"2026-02-27\"\n---\n\n# Architecture Decision Records\n\nComprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.\n\n## Use this skill when\n\n- Making significant architectural decisions\n- Documenting technology choices\n- Recording design trade-offs\n- Onboarding new team members\n- Reviewing historical decisions\n- Establishing decision-making processes\n\n## Do not use this skill when\n\n- You only need to document small implementation details\n- The change is a minor patch or routine maintenance\n- There is no architectural decision to capture\n\n## Instructions\n\n1. Capture the decision context, constraints, and drivers.\n2. Document considered options with tradeoffs.\n3. Record the decision, rationale, and consequences.\n4. Link related ADRs and update status over time.\n\n## Core Concepts\n\n### 1. What is an ADR?\n\nAn Architecture Decision Record captures:\n- **Context**: Why we needed to make a decision\n- **Decision**: What we decided\n- **Consequences**: What happens as a result\n\n### 2. When to Write an ADR\n\n| Write ADR | Skip ADR |\n|-----------|----------|\n| New framework adoption | Minor version upgrades |\n| Database technology choice | Bug fixes |\n| API design patterns | Implementation details |\n| Security architecture | Routine maintenance |\n| Integration patterns | Configuration changes |\n\n### 3. ADR Lifecycle\n\n```\nProposed → Accepted → Deprecated → Superseded\n              ↓\n           Rejected\n```\n\n## Templates\n\n### Template 1: Standard ADR (MADR Format)\n\n```markdown\n# ADR-0001: Use PostgreSQL as Primary Database\n\n## Status\n\nAccepted\n\n## Context\n\nWe need to select a primary database for our new e-commerce platform. The system\nwill handle:\n- ~10,000 concurrent users\n- Complex product catalog with hierarchical categories\n- Transaction processing for orders and payments\n- Full-text search for products\n- Geospatial queries for store locator\n\nThe team has experience with MySQL, PostgreSQL, and MongoDB. We need ACID\ncompliance for financial transactions.\n\n## Decision Drivers\n\n* **Must have ACID compliance** for payment processing\n* **Must support complex queries** for reporting\n* **Should support full-text search** to reduce infrastructure complexity\n* **Should have good JSON support** for flexible product attributes\n* **Team familiarity** reduces onboarding time\n\n## Considered Options\n\n### Option 1: PostgreSQL\n- **Pros**: ACID compliant, excellent JSON support (JSONB), built-in full-text\n  search, PostGIS for geospatial, team has experience\n- **Cons**: Slightly more complex replication setup than MySQL\n\n### Option 2: MySQL\n- **Pros**: Very familiar to team, simple replication, large community\n- **Cons**: Weaker JSON support, no built-in full-text search (need\n  Elasticsearch), no geospatial without extensions\n\n### Option 3: MongoDB\n- **Pros**: Flexible schema, native JSON, horizontal scaling\n- **Cons**: No ACID for multi-document transactions (at decision time),\n  team has limited experience, requires schema design discipline\n\n## Decision\n\nWe will use **PostgreSQL 15** as our primary database.\n\n## Rationale\n\nPostgreSQL provides the best balance of:\n1. **ACID compliance** essential for e-commerce transactions\n2. **Built-in capabilities** (full-text search, JSONB, PostGIS) reduce\n   infrastructure complexity\n3. **Team familiarity** with SQL databases reduces learning curve\n4. **Mature ecosystem** with excellent tooling and community support\n\nThe slight complexity in replication is outweighed by the reduction in\nadditional services (no separate Elasticsearch needed).\n\n## Consequences\n\n### Positive\n- Single database handles transactions, search, and geospatial queries\n- Reduced operational complexity (fewer services to manage)\n- Strong consistency guarantees for financial data\n- Team can leverage existing SQL expertise\n\n### Negative\n- Need to learn PostgreSQL-specific features (JSONB, full-text search syntax)\n- Vertical scaling limits may require read replicas sooner\n- Some team members need PostgreSQL-specific training\n\n### Risks\n- Full-text search may not scale as well as dedicated search engines\n- Mitigation: Design for potential Elasticsearch addition if needed\n\n## Implementation Notes\n\n- Use JSONB for flexible product attributes\n- Implement connection pooling with PgBouncer\n- Set up streaming replication for read replicas\n- Use pg_trgm extension for fuzzy search\n\n## Related Decisions\n\n- ADR-0002: Caching Strategy (Redis) - complements database choice\n- ADR-0005: Search Architecture - may supersede if Elasticsearch needed\n\n## References\n\n- [PostgreSQL JSON Documentation](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fdatatype-json.html)\n- [PostgreSQL Full Text Search](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Ftextsearch.html)\n- Internal: Performance benchmarks in `\u002Fdocs\u002Fbenchmarks\u002Fdatabase-comparison.md`\n```\n\n### Template 2: Lightweight ADR\n\n```markdown\n# ADR-0012: Adopt TypeScript for Frontend Development\n\n**Status**: Accepted\n**Date**: 2024-01-15\n**Deciders**: @alice, @bob, @charlie\n\n## Context\n\nOur React codebase has grown to 50+ components with increasing bug reports\nrelated to prop type mismatches and undefined errors. PropTypes provide\nruntime-only checking.\n\n## Decision\n\nAdopt TypeScript for all new frontend code. Migrate existing code incrementally.\n\n## Consequences\n\n**Good**: Catch type errors at compile time, better IDE support, self-documenting\ncode.\n\n**Bad**: Learning curve for team, initial slowdown, build complexity increase.\n\n**Mitigations**: TypeScript training sessions, allow gradual adoption with\n`allowJs: true`.\n```\n\n### Template 3: Y-Statement Format\n\n```markdown\n# ADR-0015: API Gateway Selection\n\nIn the context of **building a microservices architecture**,\nfacing **the need for centralized API management, authentication, and rate limiting**,\nwe decided for **Kong Gateway**\nand against **AWS API Gateway and custom Nginx solution**,\nto achieve **vendor independence, plugin extensibility, and team familiarity with Lua**,\naccepting that **we need to manage Kong infrastructure ourselves**.\n```\n\n### Template 4: ADR for Deprecation\n\n```markdown\n# ADR-0020: Deprecate MongoDB in Favor of PostgreSQL\n\n## Status\n\nAccepted (Supersedes ADR-0003)\n\n## Context\n\nADR-0003 (2021) chose MongoDB for user profile storage due to schema flexibility\nneeds. Since then:\n- MongoDB's multi-document transactions remain problematic for our use case\n- Our schema has stabilized and rarely changes\n- We now have PostgreSQL expertise from other services\n- Maintaining two databases increases operational burden\n\n## Decision\n\nDeprecate MongoDB and migrate user profiles to PostgreSQL.\n\n## Migration Plan\n\n1. **Phase 1** (Week 1-2): Create PostgreSQL schema, dual-write enabled\n2. **Phase 2** (Week 3-4): Backfill historical data, validate consistency\n3. **Phase 3** (Week 5): Switch reads to PostgreSQL, monitor\n4. **Phase 4** (Week 6): Remove MongoDB writes, decommission\n\n## Consequences\n\n### Positive\n- Single database technology reduces operational complexity\n- ACID transactions for user data\n- Team can focus PostgreSQL expertise\n\n### Negative\n- Migration effort (~4 weeks)\n- Risk of data issues during migration\n- Lose some schema flexibility\n\n## Lessons Learned\n\nDocument from ADR-0003 experience:\n- Schema flexibility benefits were overestimated\n- Operational cost of multiple databases was underestimated\n- Consider long-term maintenance in technology decisions\n```\n\n### Template 5: Request for Comments (RFC) Style\n\n```markdown\n# RFC-0025: Adopt Event Sourcing for Order Management\n\n## Summary\n\nPropose adopting event sourcing pattern for the order management domain to\nimprove auditability, enable temporal queries, and support business analytics.\n\n## Motivation\n\nCurrent challenges:\n1. Audit requirements need complete order history\n2. \"What was the order state at time X?\" queries are impossible\n3. Analytics team needs event stream for real-time dashboards\n4. Order state reconstruction for customer support is manual\n\n## Detailed Design\n\n### Event Store\n\n```\nOrderCreated { orderId, customerId, items[], timestamp }\nOrderItemAdded { orderId, item, timestamp }\nOrderItemRemoved { orderId, itemId, timestamp }\nPaymentReceived { orderId, amount, paymentId, timestamp }\nOrderShipped { orderId, trackingNumber, timestamp }\n```\n\n### Projections\n\n- **CurrentOrderState**: Materialized view for queries\n- **OrderHistory**: Complete timeline for audit\n- **DailyOrderMetrics**: Analytics aggregation\n\n### Technology\n\n- Event Store: EventStoreDB (purpose-built, handles projections)\n- Alternative considered: Kafka + custom projection service\n\n## Drawbacks\n\n- Learning curve for team\n- Increased complexity vs. CRUD\n- Need to design events carefully (immutable once stored)\n- Storage growth (events never deleted)\n\n## Alternatives\n\n1. **Audit tables**: Simpler but doesn't enable temporal queries\n2. **CDC from existing DB**: Complex, doesn't change data model\n3. **Hybrid**: Event source only for order state changes\n\n## Unresolved Questions\n\n- [ ] Event schema versioning strategy\n- [ ] Retention policy for events\n- [ ] Snapshot frequency for performance\n\n## Implementation Plan\n\n1. Prototype with single order type (2 weeks)\n2. Team training on event sourcing (1 week)\n3. Full implementation and migration (4 weeks)\n4. Monitoring and optimization (ongoing)\n\n## References\n\n- [Event Sourcing by Martin Fowler](https:\u002F\u002Fmartinfowler.com\u002FeaaDev\u002FEventSourcing.html)\n- [EventStoreDB Documentation](https:\u002F\u002Fwww.eventstore.com\u002Fdocs)\n```\n\n## ADR Management\n\n### Directory Structure\n\n```\ndocs\u002F\n├── adr\u002F\n│   ├── README.md           # Index and guidelines\n│   ├── template.md         # Team's ADR template\n│   ├── 0001-use-postgresql.md\n│   ├── 0002-caching-strategy.md\n│   ├── 0003-mongodb-user-profiles.md  # [DEPRECATED]\n│   └── 0020-deprecate-mongodb.md      # Supersedes 0003\n```\n\n### ADR Index (README.md)\n\n```markdown\n# Architecture Decision Records\n\nThis directory contains Architecture Decision Records (ADRs) for [Project Name].\n\n## Index\n\n| ADR | Title | Status | Date |\n|-----|-------|--------|------|\n| 0001 | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 |\n| 0002 | Caching Strategy with Redis | Accepted | 2024-01-12 |\n| 0003 | MongoDB for User Profiles | Deprecated | 2023-06-15 |\n| 0020 | Deprecate MongoDB | Accepted | 2024-01-15 |\n\n## Creating a New ADR\n\n1. Copy `template.md` to `NNNN-title-with-dashes.md`\n2. Fill in the template\n3. Submit PR for review\n4. Update this index after approval\n\n## ADR Status\n\n- **Proposed**: Under discussion\n- **Accepted**: Decision made, implementing\n- **Deprecated**: No longer relevant\n- **Superseded**: Replaced by another ADR\n- **Rejected**: Considered but not adopted\n```\n\n### Automation (adr-tools)\n\n```bash\n# Install adr-tools\nbrew install adr-tools\n\n# Initialize ADR directory\nadr init docs\u002Fadr\n\n# Create new ADR\nadr new \"Use PostgreSQL as Primary Database\"\n\n# Supersede an ADR\nadr new -s 3 \"Deprecate MongoDB in Favor of PostgreSQL\"\n\n# Generate table of contents\nadr generate toc > docs\u002Fadr\u002FREADME.md\n\n# Link related ADRs\nadr link 2 \"Complements\" 1 \"Is complemented by\"\n```\n\n## Review Process\n\n```markdown\n## ADR Review Checklist\n\n### Before Submission\n- [ ] Context clearly explains the problem\n- [ ] All viable options considered\n- [ ] Pros\u002Fcons balanced and honest\n- [ ] Consequences (positive and negative) documented\n- [ ] Related ADRs linked\n\n### During Review\n- [ ] At least 2 senior engineers reviewed\n- [ ] Affected teams consulted\n- [ ] Security implications considered\n- [ ] Cost implications documented\n- [ ] Reversibility assessed\n\n### After Acceptance\n- [ ] ADR index updated\n- [ ] Team notified\n- [ ] Implementation tickets created\n- [ ] Related documentation updated\n```\n\n## Best Practices\n\n### Do's\n- **Write ADRs early** - Before implementation starts\n- **Keep them short** - 1-2 pages maximum\n- **Be honest about trade-offs** - Include real cons\n- **Link related decisions** - Build decision graph\n- **Update status** - Deprecate when superseded\n\n### Don'ts\n- **Don't change accepted ADRs** - Write new ones to supersede\n- **Don't skip context** - Future readers need background\n- **Don't hide failures** - Rejected decisions are valuable\n- **Don't be vague** - Specific decisions, specific consequences\n- **Don't forget implementation** - ADR without action is waste\n\n## Resources\n\n- [Documenting Architecture Decisions (Michael Nygard)](https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions)\n- [MADR Template](https:\u002F\u002Fadr.github.io\u002Fmadr\u002F)\n- [ADR GitHub Organization](https:\u002F\u002Fadr.github.io\u002F)\n- [adr-tools](https:\u002F\u002Fgithub.com\u002Fnpryce\u002Fadr-tools)\n","# Architecture Decision Records\n\nComprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.\n\n## Use this skill when\n\n- Making significant architectural decisions\n- Documenting technology choices\n- Recording design trade-offs\n- Onboarding new team members\n- Reviewing historical decisions\n- Establishing decision-making processes\n\n## Do not use this skill when\n\n- You only need to document small implementation details\n- The change is a minor patch or routine maintenance\n- There is no architectural decision to capture\n\n## Instructions\n\n1. Capture the decision context, constraints, and drivers.\n2. Document considered options with tradeoffs.\n3. Record the decision, rationale, and consequences.\n4. Link related ADRs and update status over time.\n\n## Core Concepts\n\n### 1. What is an ADR?\n\nAn Architecture Decision Record captures:\n- **Context**: Why we needed to make a decision\n- **Decision**: What we decided\n- **Consequences**: What happens as a result\n\n### 2. When to Write an ADR\n\n| Write ADR | Skip ADR |\n|-----------|----------|\n| New framework adoption | Minor version upgrades |\n| Database technology choice | Bug fixes |\n| API design patterns | Implementation details |\n| Security architecture | Routine maintenance |\n| Integration patterns | Configuration changes |\n\n### 3. ADR Lifecycle\n\n```\nProposed → Accepted → Deprecated → Superseded\n              ↓\n           Rejected\n```\n\n## Templates\n\n### Template 1: Standard ADR (MADR Format)\n\n```markdown\n# ADR-0001: Use PostgreSQL as Primary Database\n\n## Status\n\nAccepted\n\n## Context\n\nWe need to select a primary database for our new e-commerce platform. The system\nwill handle:\n- ~10,000 concurrent users\n- Complex product catalog with hierarchical categories\n- Transaction processing for orders and payments\n- Full-text search for products\n- Geospatial queries for store locator\n\nThe team has experience with MySQL, PostgreSQL, and MongoDB. We need ACID\ncompliance for financial transactions.\n\n## Decision Drivers\n\n* **Must have ACID compliance** for payment processing\n* **Must support complex queries** for reporting\n* **Should support full-text search** to reduce infrastructure complexity\n* **Should have good JSON support** for flexible product attributes\n* **Team familiarity** reduces onboarding time\n\n## Considered Options\n\n### Option 1: PostgreSQL\n- **Pros**: ACID compliant, excellent JSON support (JSONB), built-in full-text\n  search, PostGIS for geospatial, team has experience\n- **Cons**: Slightly more complex replication setup than MySQL\n\n### Option 2: MySQL\n- **Pros**: Very familiar to team, simple replication, large community\n- **Cons**: Weaker JSON support, no built-in full-text search (need\n  Elasticsearch), no geospatial without extensions\n\n### Option 3: MongoDB\n- **Pros**: Flexible schema, native JSON, horizontal scaling\n- **Cons**: No ACID for multi-document transactions (at decision time),\n  team has limited experience, requires schema design discipline\n\n## Decision\n\nWe will use **PostgreSQL 15** as our primary database.\n\n## Rationale\n\nPostgreSQL provides the best balance of:\n1. **ACID compliance** essential for e-commerce transactions\n2. **Built-in capabilities** (full-text search, JSONB, PostGIS) reduce\n   infrastructure complexity\n3. **Team familiarity** with SQL databases reduces learning curve\n4. **Mature ecosystem** with excellent tooling and community support\n\nThe slight complexity in replication is outweighed by the reduction in\nadditional services (no separate Elasticsearch needed).\n\n## Consequences\n\n### Positive\n- Single database handles transactions, search, and geospatial queries\n- Reduced operational complexity (fewer services to manage)\n- Strong consistency guarantees for financial data\n- Team can leverage existing SQL expertise\n\n### Negative\n- Need to learn PostgreSQL-specific features (JSONB, full-text search syntax)\n- Vertical scaling limits may require read replicas sooner\n- Some team members need PostgreSQL-specific training\n\n### Risks\n- Full-text search may not scale as well as dedicated search engines\n- Mitigation: Design for potential Elasticsearch addition if needed\n\n## Implementation Notes\n\n- Use JSONB for flexible product attributes\n- Implement connection pooling with PgBouncer\n- Set up streaming replication for read replicas\n- Use pg_trgm extension for fuzzy search\n\n## Related Decisions\n\n- ADR-0002: Caching Strategy (Redis) - complements database choice\n- ADR-0005: Search Architecture - may supersede if Elasticsearch needed\n\n## References\n\n- [PostgreSQL JSON Documentation](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fdatatype-json.html)\n- [PostgreSQL Full Text Search](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Ftextsearch.html)\n- Internal: Performance benchmarks in `\u002Fdocs\u002Fbenchmarks\u002Fdatabase-comparison.md`\n```\n\n### Template 2: Lightweight ADR\n\n```markdown\n# ADR-0012: Adopt TypeScript for Frontend Development\n\n**Status**: Accepted\n**Date**: 2024-01-15\n**Deciders**: @alice, @bob, @charlie\n\n## Context\n\nOur React codebase has grown to 50+ components with increasing bug reports\nrelated to prop type mismatches and undefined errors. PropTypes provide\nruntime-only checking.\n\n## Decision\n\nAdopt TypeScript for all new frontend code. Migrate existing code incrementally.\n\n## Consequences\n\n**Good**: Catch type errors at compile time, better IDE support, self-documenting\ncode.\n\n**Bad**: Learning curve for team, initial slowdown, build complexity increase.\n\n**Mitigations**: TypeScript training sessions, allow gradual adoption with\n`allowJs: true`.\n```\n\n### Template 3: Y-Statement Format\n\n```markdown\n# ADR-0015: API Gateway Selection\n\nIn the context of **building a microservices architecture**,\nfacing **the need for centralized API management, authentication, and rate limiting**,\nwe decided for **Kong Gateway**\nand against **AWS API Gateway and custom Nginx solution**,\nto achieve **vendor independence, plugin extensibility, and team familiarity with Lua**,\naccepting that **we need to manage Kong infrastructure ourselves**.\n```\n\n### Template 4: ADR for Deprecation\n\n```markdown\n# ADR-0020: Deprecate MongoDB in Favor of PostgreSQL\n\n## Status\n\nAccepted (Supersedes ADR-0003)\n\n## Context\n\nADR-0003 (2021) chose MongoDB for user profile storage due to schema flexibility\nneeds. Since then:\n- MongoDB's multi-document transactions remain problematic for our use case\n- Our schema has stabilized and rarely changes\n- We now have PostgreSQL expertise from other services\n- Maintaining two databases increases operational burden\n\n## Decision\n\nDeprecate MongoDB and migrate user profiles to PostgreSQL.\n\n## Migration Plan\n\n1. **Phase 1** (Week 1-2): Create PostgreSQL schema, dual-write enabled\n2. **Phase 2** (Week 3-4): Backfill historical data, validate consistency\n3. **Phase 3** (Week 5): Switch reads to PostgreSQL, monitor\n4. **Phase 4** (Week 6): Remove MongoDB writes, decommission\n\n## Consequences\n\n### Positive\n- Single database technology reduces operational complexity\n- ACID transactions for user data\n- Team can focus PostgreSQL expertise\n\n### Negative\n- Migration effort (~4 weeks)\n- Risk of data issues during migration\n- Lose some schema flexibility\n\n## Lessons Learned\n\nDocument from ADR-0003 experience:\n- Schema flexibility benefits were overestimated\n- Operational cost of multiple databases was underestimated\n- Consider long-term maintenance in technology decisions\n```\n\n### Template 5: Request for Comments (RFC) Style\n\n```markdown\n# RFC-0025: Adopt Event Sourcing for Order Management\n\n## Summary\n\nPropose adopting event sourcing pattern for the order management domain to\nimprove auditability, enable temporal queries, and support business analytics.\n\n## Motivation\n\nCurrent challenges:\n1. Audit requirements need complete order history\n2. \"What was the order state at time X?\" queries are impossible\n3. Analytics team needs event stream for real-time dashboards\n4. Order state reconstruction for customer support is manual\n\n## Detailed Design\n\n### Event Store\n\n```\nOrderCreated { orderId, customerId, items[], timestamp }\nOrderItemAdded { orderId, item, timestamp }\nOrderItemRemoved { orderId, itemId, timestamp }\nPaymentReceived { orderId, amount, paymentId, timestamp }\nOrderShipped { orderId, trackingNumber, timestamp }\n```\n\n### Projections\n\n- **CurrentOrderState**: Materialized view for queries\n- **OrderHistory**: Complete timeline for audit\n- **DailyOrderMetrics**: Analytics aggregation\n\n### Technology\n\n- Event Store: EventStoreDB (purpose-built, handles projections)\n- Alternative considered: Kafka + custom projection service\n\n## Drawbacks\n\n- Learning curve for team\n- Increased complexity vs. CRUD\n- Need to design events carefully (immutable once stored)\n- Storage growth (events never deleted)\n\n## Alternatives\n\n1. **Audit tables**: Simpler but doesn't enable temporal queries\n2. **CDC from existing DB**: Complex, doesn't change data model\n3. **Hybrid**: Event source only for order state changes\n\n## Unresolved Questions\n\n- [ ] Event schema versioning strategy\n- [ ] Retention policy for events\n- [ ] Snapshot frequency for performance\n\n## Implementation Plan\n\n1. Prototype with single order type (2 weeks)\n2. Team training on event sourcing (1 week)\n3. Full implementation and migration (4 weeks)\n4. Monitoring and optimization (ongoing)\n\n## References\n\n- [Event Sourcing by Martin Fowler](https:\u002F\u002Fmartinfowler.com\u002FeaaDev\u002FEventSourcing.html)\n- [EventStoreDB Documentation](https:\u002F\u002Fwww.eventstore.com\u002Fdocs)\n```\n\n## ADR Management\n\n### Directory Structure\n\n```\ndocs\u002F\n├── adr\u002F\n│   ├── README.md           # Index and guidelines\n│   ├── template.md         # Team's ADR template\n│   ├── 0001-use-postgresql.md\n│   ├── 0002-caching-strategy.md\n│   ├── 0003-mongodb-user-profiles.md  # [DEPRECATED]\n│   └── 0020-deprecate-mongodb.md      # Supersedes 0003\n```\n\n### ADR Index (README.md)\n\n```markdown\n# Architecture Decision Records\n\nThis directory contains Architecture Decision Records (ADRs) for [Project Name].\n\n## Index\n\n| ADR | Title | Status | Date |\n|-----|-------|--------|------|\n| 0001 | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 |\n| 0002 | Caching Strategy with Redis | Accepted | 2024-01-12 |\n| 0003 | MongoDB for User Profiles | Deprecated | 2023-06-15 |\n| 0020 | Deprecate MongoDB | Accepted | 2024-01-15 |\n\n## Creating a New ADR\n\n1. Copy `template.md` to `NNNN-title-with-dashes.md`\n2. Fill in the template\n3. Submit PR for review\n4. Update this index after approval\n\n## ADR Status\n\n- **Proposed**: Under discussion\n- **Accepted**: Decision made, implementing\n- **Deprecated**: No longer relevant\n- **Superseded**: Replaced by another ADR\n- **Rejected**: Considered but not adopted\n```\n\n### Automation (adr-tools)\n\n```bash\n# Install adr-tools\nbrew install adr-tools\n\n# Initialize ADR directory\nadr init docs\u002Fadr\n\n# Create new ADR\nadr new \"Use PostgreSQL as Primary Database\"\n\n# Supersede an ADR\nadr new -s 3 \"Deprecate MongoDB in Favor of PostgreSQL\"\n\n# Generate table of contents\nadr generate toc > docs\u002Fadr\u002FREADME.md\n\n# Link related ADRs\nadr link 2 \"Complements\" 1 \"Is complemented by\"\n```\n\n## Review Process\n\n```markdown\n## ADR Review Checklist\n\n### Before Submission\n- [ ] Context clearly explains the problem\n- [ ] All viable options considered\n- [ ] Pros\u002Fcons balanced and honest\n- [ ] Consequences (positive and negative) documented\n- [ ] Related ADRs linked\n\n### During Review\n- [ ] At least 2 senior engineers reviewed\n- [ ] Affected teams consulted\n- [ ] Security implications considered\n- [ ] Cost implications documented\n- [ ] Reversibility assessed\n\n### After Acceptance\n- [ ] ADR index updated\n- [ ] Team notified\n- [ ] Implementation tickets created\n- [ ] Related documentation updated\n```\n\n## Best Practices\n\n### Do's\n- **Write ADRs early** - Before implementation starts\n- **Keep them short** - 1-2 pages maximum\n- **Be honest about trade-offs** - Include real cons\n- **Link related decisions** - Build decision graph\n- **Update status** - Deprecate when superseded\n\n### Don'ts\n- **Don't change accepted ADRs** - Write new ones to supersede\n- **Don't skip context** - Future readers need background\n- **Don't hide failures** - Rejected decisions are valuable\n- **Don't be vague** - Specific decisions, specific consequences\n- **Don't forget implementation** - ADR without action is waste\n\n## Resources\n\n- [Documenting Architecture Decisions (Michael Nygard)](https:\u002F\u002Fcognitect.com\u002Fblog\u002F2011\u002F11\u002F15\u002Fdocumenting-architecture-decisions)\n- [MADR Template](https:\u002F\u002Fadr.github.io\u002Fmadr\u002F)\n- [ADR GitHub Organization](https:\u002F\u002Fadr.github.io\u002F)\n- [adr-tools](https:\u002F\u002Fgithub.com\u002Fnpryce\u002Fadr-tools)\n",{"name":5,"risk":31,"source":28,"date_added":39,"description":7},"2026-02-27","main","7a38d8e7073e61c16eda85681cb32fb68a8657a5","skills-store\u002Fcursor\u002Farchitecture-decision-records","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router","https:\u002F\u002Fgithub.com\u002Fsapsapshen","2026-04-14 21:12:12",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add sapsapshen\u002Fai-memory-router --skill architecture-decision-records",{"tool":52,"command":53},"bunx","bunx skills add sapsapshen\u002Fai-memory-router --skill architecture-decision-records",{"tool":55,"command":56},"pnpm","pnpm dlx skills add sapsapshen\u002Fai-memory-router --skill architecture-decision-records","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fcursor\u002Farchitecture-decision-records\u002FSKILL.md",true,[],[61,85,111,121,134,153],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":72,"publishedAt":34},"01M71ATQRKG48SH06FQ697T5G9","wechat-search","Search WeChat Official Account articles using OpenClaw's web search and fetch capabilities with compliance-focused design.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fwechat-search-release\u002FSKILL.md",[67],{"categoryNo":68,"categoryName":69,"taxonomyType":70,"taxonomyTypeDesc":71},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[73,74,75,76,77,78,79,80,81,82,83,84],"wechat search","wechat","search","capabilities","openclaw","design","web search","compliance","web","official","fetch","with",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":34},"01M71ATNAVGZB35PFYM2GC5N00","trend-tap","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend tap', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-tap\u002FSKILL.md",[],[92,93,94,95,96,97,75,98,99,100,101,102,103,104,105,106,107,108,109,110],"trend","trend tap","tap","api keys","Bash","time","trending","hacker","aggregator","do","when","brew","live","data","google","install","read","across","api",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":34},"01M71ATJ9AM5KM15AA8PS302EB","trend-radar","Real-time trending topics aggregator across 7 platforms (X\u002FTwitter, Reddit, Google Trends, Hacker News, Zhihu, Bilibili, Weibo). Trigger: when user says 'trend', 'trends', 'trend pulse', '热点', '热搜', or asks what is trending\u002Fhot. Do NOT use web_search — this skill already fetches live data from all platforms with zero API keys.","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftrend-radar\u002FSKILL.md",[],[118,119,92,103,104,105,106,96,75,108,120,109,110,102,100,99,98,107,97,95],"trend radar","radar","pulse",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":34},"01M71ATGF095N3EJM9G8SD0BB5","tech-news-daily","每日科技新闻汇——从全球多个 RSS 源抓取最新科技新闻，翻译（英→中）、去重、排版成每日简报。当用户询问科技新闻、科技新鲜事、每日科技、技术动态、Daily Tech News 或类似表达时触发此技能。","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Ftech-news-daily\u002FSKILL.md",[],[128,129,130,131,132,133],"news","tech","tech news daily","daily","rss","翻译",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":145,"publishedAt":34},"01M71ATFAEAMQ17M70NQNY7SR8","summarize","Summarize URLs or files with the summarize CLI (web, PDFs, images, audio, YouTube).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsummarize\u002FSKILL.md",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[136,81,146,147,148,84,103,149,150,151,94,152,107],"Audio","cli","youtube","images","https","files","pdfs",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":34},"01M71ATDNS3R0M4H936PACQAWZ","sonoscli","Control Sonos speakers (discover\u002Fstatus\u002Fplay\u002Fvolume\u002Fgroup).","https:\u002F\u002Fgithub.com\u002Fsapsapshen\u002Fai-memory-router\u002Fblob\u002Fmain\u002Fskills-store\u002Fopenclaw\u002Fsonoscli\u002FSKILL.md",[],[155,160,161,162,107,163,150,164,165,166,167,168],"status","play","go","latest","github","discover","control","cmd","volume"]