@zigrivers/scaffold 3.33.0 → 3.33.1

package/content/knowledge/VERSION

@@ -1 +1 @@
-0.1.0
+0.1.2

package/content/knowledge/backend/backend-api-design.md

@@ -1,15 +1,33 @@
 ---
 name: backend-api-design
-description: REST maturity levels, GraphQL schema-first design, gRPC protobuf conventions, tRPC router patterns, API versioning strategies, pagination, and filtering
-topics: [backend, api-design, rest, graphql, grpc, trpc, versioning, pagination]
+description: >-
+  REST maturity levels, GraphQL schema-first design, gRPC protobuf conventions, tRPC router patterns, API versioning
+  strategies, pagination, and filtering
+topics:
+  - backend
+  - api-design
+  - rest
+  - graphql
+  - grpc
+  - trpc
+  - versioning
+  - pagination
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2025-10-27
 version-pin: null
 sources:
   - url: https://spec.openapis.org/oas/latest.html
+    hash: sha256:15f12e539a3ac811c5f18950bc9cff296b43a22ad4d50b4db8d533f37ebc1d23
+    retrieved: 2025-10-27
   - url: https://spec.graphql.org/
+    hash: sha256:14221cbb56b50b8179803abd08a5f801ebbca98c2d97eb86b47469284a3b88cf
+    retrieved: 2025-10-27
   - url: https://www.rfc-editor.org/rfc/rfc9110.html
+    hash: sha256:d431760660ea44e130f6e919dab216df2d0b3a490567a98089267523368fe1e5
+    retrieved: 2025-10-27
   - url: https://martinfowler.com/articles/richardsonMaturityModel.html
+    hash: sha256:67fe98bd0c4572223f6973109e515fade396e29a3fc6ccb2323409392c91b501
+    retrieved: 2025-10-27
 ---
 
 API design is a long-lived contract. Every structural decision — URL shape, error format, pagination scheme, versioning strategy — is expensive to change after consumers depend on it. Design APIs from the consumer's perspective first. The best API is one where new developers can predict the shape of an endpoint they have never seen before, because every other endpoint follows the same patterns.

package/content/knowledge/backend/backend-architecture.md

@@ -1,15 +1,33 @@
 ---
 name: backend-architecture
-description: Monolith vs microservices decision framework, layered architecture patterns, CQRS, event sourcing, hexagonal architecture, and service mesh considerations
-topics: [backend, architecture, microservices, monolith, cqrs, event-sourcing, hexagonal, clean-architecture]
+description: >-
+  Monolith vs microservices decision framework, layered architecture patterns, CQRS, event sourcing, hexagonal
+  architecture, and service mesh considerations
+topics:
+  - backend
+  - architecture
+  - microservices
+  - monolith
+  - cqrs
+  - event-sourcing
+  - hexagonal
+  - clean-architecture
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2025-07-17
 version-pin: null
 sources:
   - url: https://microservices.io/patterns/
+    hash: sha256:fa1ff9ebd46faa3f90ad25e7f536a78019167c61e03186be6cbb08c46367db5d
+    retrieved: 2025-07-17
   - url: https://martinfowler.com/bliki/CQRS.html
+    hash: sha256:11cf46ce308805e94e4b110016b09d004fbf8c47669a7041080f661c798b2f29
+    retrieved: 2025-07-17
   - url: https://martinfowler.com/eaaDev/EventSourcing.html
+    hash: sha256:8c266ad1f81881deac8a59d86f429a594497eac3243aa1bd5b40202ccfada596
+    retrieved: 2025-07-17
   - url: https://martinfowler.com/bliki/MonolithFirst.html
+    hash: sha256:722d8d78beddd9e0f6ff3e856eec94dfa2b9fa3bebcaaf4c9e80ccdd3c0e1446
+    retrieved: 2025-07-17
 ---
 
 Backend architecture is the set of structural decisions that determine how the system scales, how teams work independently, and how expensive future changes will be. The single most common backend architecture mistake is choosing microservices before the problem demands them. Start with the simplest architecture that solves the current problem, and evolve to complexity only when specific pain points — not hypothetical future ones — force the change.

package/content/knowledge/backend/backend-async-patterns.md

@@ -1,14 +1,28 @@
 ---
 name: backend-async-patterns
 description: Message queue patterns, event-driven architecture, saga patterns, retry strategies, and idempotency keys
-topics: [backend, async, message-queues, event-driven, saga, retry, idempotency, cqrs]
+topics:
+  - backend
+  - async
+  - message-queues
+  - event-driven
+  - saga
+  - retry
+  - idempotency
+  - cqrs
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2025-04-08
 version-pin: null
 sources:
   - url: https://microservices.io/patterns/data/saga.html
+    hash: sha256:c42eac244bf94f8db7767ba131c1715066a2dd10beb1cd6f01e5f92e19d2f0b3
+    retrieved: 2025-04-08
   - url: https://martinfowler.com/articles/patterns-of-distributed-systems/
+    hash: sha256:93092f76ea34af4d60c068180a063d9fde27ab6c7b604ba42337aeed023cab86
+    retrieved: 2025-04-08
   - url: https://sre.google/sre-book/handling-overload/
+    hash: sha256:8ca912a82390e7f61e8bbae7baab3a74489f5068d71dee1ff24aed99375e0373
+    retrieved: 2025-04-08
 ---
 
 Asynchronous patterns decouple services in time and space, enabling systems to absorb load spikes, survive partial failures, and scale independently — but they introduce delivery guarantees and consistency tradeoffs that must be designed for explicitly from the start.

package/content/knowledge/backend/backend-auth-patterns.md

@@ -1,16 +1,33 @@
 ---
 name: backend-auth-patterns
 description: JWT lifecycle, OAuth2 authorization code flow, API key management, and service-to-service authentication
-topics: [backend, auth, jwt, oauth2, api-keys, mtls, security]
+topics:
+  - backend
+  - auth
+  - jwt
+  - oauth2
+  - api-keys
+  - mtls
+  - security
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2025-05-27
 version-pin: null
 sources:
   - url: https://www.rfc-editor.org/rfc/rfc6749
+    hash: sha256:728b767bd41293b9fc83f233f9f115f4aea0b044e370084d29fb1269e09615aa
+    retrieved: 2025-05-27
   - url: https://www.rfc-editor.org/rfc/rfc7519
+    hash: sha256:9d96b6f50503146ef45359bb95d559edca5e73924ac97790c0bf19a707644774
+    retrieved: 2025-05-27
   - url: https://www.rfc-editor.org/rfc/rfc7636
+    hash: sha256:c98037dc067089b2fe04e4383f2b6356c70ccb9568dd654a15c5f31f5a0ef1eb
+    retrieved: 2025-05-27
   - url: https://openid.net/specs/openid-connect-core-1_0.html
+    hash: sha256:4d016752a645e8a3c259baa4173b5a90cb6c82898ce868fc8444adde262a5aed
+    retrieved: 2025-05-27
   - url: https://owasp.org/www-project-api-security/
+    hash: sha256:08a9c96c69b3707a812ef8f919284e21890ec73fdcea50783ce868c9d546c1bd
+    retrieved: 2025-05-27
 ---
 
 Authentication and authorization are the first line of defense for any backend service — mistakes here compromise the entire system, making it essential to use proven patterns like JWTs with rotation, OAuth2 with PKCE, and workload identity from the start.

package/content/knowledge/backend/backend-conventions.md

@@ -1,13 +1,25 @@
 ---
 name: backend-conventions
-description: Service and handler naming conventions, structured error handling patterns, structured logging with correlation IDs, and file organization standards for backend codebases
-topics: [backend, conventions, error-handling, logging, naming, file-organization]
+description: >-
+  Service and handler naming conventions, structured error handling patterns, structured logging with correlation IDs,
+  and file organization standards for backend codebases
+topics:
+  - backend
+  - conventions
+  - error-handling
+  - logging
+  - naming
+  - file-organization
 volatility: stable
-last-reviewed: null
+last-reviewed: 2025-01-15
 version-pin: null
 sources:
   - url: https://google.github.io/styleguide/
+    hash: sha256:e40c3a5dfb0a54715f3e120b309a11b7707e03143399f746ea651ad0a74c983f
+    retrieved: 2025-01-15
   - url: https://martinfowler.com/tags/clean%20code.html
+    hash: sha256:7b8d78e227d63880ce0b2884da4deda09aa223d43f81614630a5a86d7f766ee3
+    retrieved: 2025-01-15
 ---
 
 Consistent conventions in a backend codebase reduce cognitive load, make code reviewable at a glance, and prevent entire classes of bugs. Naming, error handling, and logging are the three highest-leverage areas — they touch every layer of the stack and every engineer on the team. Establish these conventions before the first PR, codify them in linting rules where possible, and treat violations as blocking review comments.

package/content/knowledge/backend/backend-data-modeling.md

@@ -1,14 +1,30 @@
 ---
 name: backend-data-modeling
-description: Relational vs document modeling tradeoffs, migration strategies, connection pooling, ORM vs query builder tradeoffs, multi-tenancy patterns, and eventual consistency
-topics: [backend, data-modeling, database, migrations, orm, multi-tenancy, eventual-consistency, connection-pooling]
+description: >-
+  Relational vs document modeling tradeoffs, migration strategies, connection pooling, ORM vs query builder tradeoffs,
+  multi-tenancy patterns, and eventual consistency
+topics:
+  - backend
+  - data-modeling
+  - database
+  - migrations
+  - orm
+  - multi-tenancy
+  - eventual-consistency
+  - connection-pooling
 volatility: stable
-last-reviewed: null
+last-reviewed: 2026-05-15
 version-pin: null
 sources:
   - url: https://www.postgresql.org/docs/current/
+    hash: sha256:5fc8b49295f6c1c6a80ddab08d20f6aa2395e9804353fc4e8e8f57e77564d3f2
+    retrieved: 2026-05-15
   - url: https://martinfowler.com/articles/evodb.html
+    hash: sha256:77d7c85db8a99f4b194e89bec6e0cd14e860cce0f54475326823894ce5b3a289
+    retrieved: 2026-05-15
   - url: https://microservices.io/patterns/data/database-per-service.html
+    hash: sha256:014afb315804d3d1464b1ac4c021c0abe9ab215ee6c49745a4ed57f542b35de6
+    retrieved: 2026-05-15
 ---
 
 Data modeling decisions have the highest reversal cost of any backend choice. A schema design that seemed reasonable at launch can become an operational crisis at scale — queries that worked at 10,000 rows fail at 100 million. The goal is to match the data model to the access patterns of the application, not to normalize for its own sake or to denormalize prematurely. Design the schema with the queries in mind from day one.

package/content/knowledge/backend/backend-deployment.md

@@ -1,15 +1,33 @@
 ---
 name: backend-deployment
-description: Containerization best practices, serverless patterns, health check endpoints, graceful shutdown, and deployment strategies
-topics: [backend, deployment, docker, serverless, health-checks, graceful-shutdown, blue-green, canary]
+description: >-
+  Containerization best practices, serverless patterns, health check endpoints, graceful shutdown, and deployment
+  strategies
+topics:
+  - backend
+  - deployment
+  - docker
+  - serverless
+  - health-checks
+  - graceful-shutdown
+  - blue-green
+  - canary
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2025-01-14
 version-pin: null
 sources:
   - url: https://martinfowler.com/bliki/BlueGreenDeployment.html
+    hash: sha256:eeb9a79a1caab2e9ffcafdfcfb12d9d6669918a7f2af3e9f44087458d0951717
+    retrieved: 2025-01-14
   - url: https://martinfowler.com/bliki/CanaryRelease.html
+    hash: sha256:916caf0f38ffd564c0c478b51d7e5dac9fdbc4fa8bb9b6729300fc96d27c2715
+    retrieved: 2025-01-14
   - url: https://sre.google/sre-book/release-engineering/
+    hash: sha256:eb0116a837c4f1b94eff42bde5a47a0a59874c8b432e3bf070374883ec558a54
+    retrieved: 2025-01-14
   - url: https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/welcome.html
+    hash: sha256:1e7eac9d22264bbc9dbca009645063474ea47d8940b21d15b1d68f03b0a1f4ee
+    retrieved: 2025-01-14
 ---
 
 Deployment reliability is a multiplier on every other engineering investment — a well-written service that deploys poorly will cause more incidents than a mediocre service that deploys safely and rolls back cleanly.

package/content/knowledge/backend/backend-dev-environment.md

@@ -1,12 +1,22 @@
 ---
 name: backend-dev-environment
-description: Docker Compose for local databases and queues, database seeding and migration scripts, API testing tools, environment variable management, and local SSL setup
-topics: [backend, dev-environment, docker, migrations, testing, environment-variables]
+description: >-
+  Docker Compose for local databases and queues, database seeding and migration scripts, API testing tools, environment
+  variable management, and local SSL setup
+topics:
+  - backend
+  - dev-environment
+  - docker
+  - migrations
+  - testing
+  - environment-variables
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2026-05-15
 version-pin: null
 sources:
   - url: https://www.postgresql.org/docs/current/
+    hash: sha256:5fc8b49295f6c1c6a80ddab08d20f6aa2395e9804353fc4e8e8f57e77564d3f2
+    retrieved: 2026-05-15
 ---
 
 A backend development environment that requires manual setup steps is a productivity drain and an onboarding failure. The standard should be: clone the repo, run one command, and have a fully functional local environment in under five minutes. Docker Compose is the primary tool for achieving this — it pins the exact versions of every external dependency and makes the environment reproducible across all developer machines.

package/content/knowledge/backend/backend-fintech-broker-integration.md

@@ -1,13 +1,25 @@
 ---
 name: backend-fintech-broker-integration
 description: Multi-broker adapter pattern; credential rotation; error harmonization; rate-limit management; broker-side quirks.
-topics: [backend, fintech, brokers, integration, adapter-pattern, rate-limits, credentials, retry]
+topics:
+  - backend
+  - fintech
+  - brokers
+  - integration
+  - adapter-pattern
+  - rate-limits
+  - credentials
+  - retry
 volatility: evolving
-last-reviewed: null
+last-reviewed: 2025-04-08
 version-pin: null
 sources:
   - url: https://microservices.io/patterns/reliability/circuit-breaker.html
+    hash: sha256:a117f72fc0d279ea99d4234ea8a8cc7bdf23d7ed59d94effc6129d613518a6fa
+    retrieved: 2025-04-08
   - url: https://martinfowler.com/bliki/CircuitBreaker.html
+    hash: sha256:73239948ec03887430a4d139e384e94bc640fec894fb1dce53b56abe579c5da4
+    retrieved: 2025-04-08
 ---
 
 A fintech backend that routes orders or reads positions across more than one broker inherits the union of every broker's quirks, outages, auth schemes, and undocumented behaviors. The broker-integration layer exists to hide that mess behind one normalized internal contract so the rest of the system — risk, order lifecycle, ledger, UI — can stay clean. This doc covers the adapter contract, credential handling, error harmonization, rate-limit strategy, and the specific pitfalls that recur regardless of which brokers you connect.

package/content/knowledge/backend/backend-fintech-compliance.md

@@ -1,15 +1,34 @@
 ---
 name: backend-fintech-compliance
-description: PCI-DSS, SOC 2, SEC/FINRA regulations for consumer/B2B fintech backends; audit trail immutability; data retention; segregation of duties.
-topics: [backend, fintech, compliance, pci-dss, soc2, sec, finra, audit-trail, gdpr]
+description: >-
+  PCI-DSS, SOC 2, SEC/FINRA regulations for consumer/B2B fintech backends; audit trail immutability; data retention;
+  segregation of duties.
+topics:
+  - backend
+  - fintech
+  - compliance
+  - pci-dss
+  - soc2
+  - sec
+  - finra
+  - audit-trail
+  - gdpr
 volatility: evolving
-last-reviewed: null
-version-pin: 'PCI-DSS v4.0.1'
+last-reviewed: 2025-06-01
+version-pin: PCI-DSS v4.0.1
 sources:
   - url: https://www.pcisecuritystandards.org/document_library/
+    hash: sha256:9cb04202115fe2c3275274d93a4eb506c0f97648af0dcee12dc1da0faec0bcbf
+    retrieved: 2025-06-01
   - url: https://www.aicpa-cima.com/topic/audit-assurance
+    hash: sha256:08d2df6fd46adb5e0c62200435b8619d9dd67228ef1c9ce5cbe19e87f048a667
+    retrieved: 2025-06-01
   - url: https://www.finra.org/rules-guidance/rulebooks/finra-rules
+    hash: sha256:0ddd688189c919aeb3903adf06a0a727b515c9a51482c62bf9fdb77f53980e14
+    retrieved: 2025-06-01
   - url: https://eur-lex.europa.eu/eli/reg/2016/679/oj
+    hash: sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+    retrieved: 2025-06-01
 ---
 
 Fintech compliance is not a checklist applied at the end — it determines schema design, deployment pipelines, and system boundaries. Most regulations apply based on what a service *touches* (cards, trades, PII), so scope reduction is the single highest-leverage design decision available to engineering. This doc covers the regulatory regimes a typical US/EU fintech encounters, the audit-trail patterns they demand, and concrete implementation choices that keep audits survivable.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zigrivers/scaffold",
-  "version": "3.33.0",
+  "version": "3.33.1",
   "description": "AI-powered software project scaffolding pipeline",
   "type": "module",
   "workspaces": [