@zigrivers/scaffold 3.28.0 → 3.29.0

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

@@ -2,6 +2,12 @@
 name: backend-fintech-testing
 description: Deterministic backtests; financial-accuracy tests; broker sandbox testing; regulatory edge-case coverage.
 topics: [backend, fintech, testing, determinism, backtesting, sandbox, accuracy, property-based]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.pact.io/
+  - url: https://martinfowler.com/articles/practical-test-pyramid.html
 ---
 
 Fintech tests have unusual requirements: bit-exact numeric accuracy, full determinism across runs and hosts, rich regulatory edge-case coverage, and realistic multi-session flows that span market-hours boundaries. A flakey fintech test is worse than no test — it hides the exact race conditions that cause real money to move incorrectly. This doc covers the patterns that keep backtests reproducible, numeric tests honest, broker integrations verifiable, and regulatory behavior exercised before it becomes an incident.

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

@@ -2,6 +2,13 @@
 name: backend-observability
 description: Structured logging, distributed tracing, RED method metrics, SLO-based alerting, and operational dashboards
 topics: [backend, observability, logging, tracing, metrics, alerting, opentelemetry, slo]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://opentelemetry.io/docs/
+  - url: https://sre.google/sre-book/service-level-objectives/
+  - url: https://sre.google/sre-book/monitoring-distributed-systems/
 ---
 
 Observability is the ability to answer arbitrary questions about a system's behavior using its outputs alone — without deploying new code. Investing in structured logging, distributed tracing, and SLO-based alerting before the first incident makes the difference between a 5-minute diagnosis and a 5-hour outage.

package/content/knowledge/backend/backend-project-structure.md

@@ -2,6 +2,12 @@
 name: backend-project-structure
 description: Canonical directory layout for backend services — routes/controllers, services, models/repositories, middleware, utils, config resolution, and dependency injection patterns
 topics: [backend, project-structure, architecture, dependency-injection, layers]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/eaaCatalog/
+  - url: https://martinfowler.com/articles/injection.html
 ---
 
 A well-organized backend project is readable to a new engineer in minutes. The directory layout should communicate the architecture: which layer owns which responsibility, where to add a new feature, and where to find any piece of behavior. The most common structural failure is mixing concerns — business logic in controllers, database calls in services, HTTP parsing in repositories. Enforce boundaries through structure first, tooling second.

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

@@ -2,6 +2,12 @@
 name: backend-requirements
 description: API-first design principles, SLA requirements (latency p99, uptime, throughput), scalability targets, backwards compatibility commitments, and API versioning strategy
 topics: [backend, requirements, sla, api, versioning, scalability, performance]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://spec.openapis.org/oas/latest.html
+  - url: https://sre.google/sre-book/service-level-objectives/
 ---
 
 Backend requirements are the contract the service makes with its consumers — other teams, external developers, and end users. Setting explicit SLAs, versioning policies, and scalability targets before any code is written eliminates the most expensive class of late-breaking architectural changes. A backend that surprises its callers with latency spikes or breaking changes destroys trust and creates cascading toil.

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

@@ -2,6 +2,13 @@
 name: backend-security
 description: Input validation, SQL injection prevention, rate limiting, OWASP API Security Top 10, secrets management, and dependency auditing
 topics: [backend, security, validation, sql-injection, rate-limiting, owasp, secrets]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/www-project-api-security/
+  - url: https://owasp.org/www-project-top-ten/
+  - url: https://owasp.org/www-project-cheat-sheets/
 ---
 
 Security vulnerabilities in backend services are disproportionately expensive to fix after launch — building in input validation, injection prevention, rate limiting, and secrets hygiene from the start is always cheaper than retrofitting them under pressure after a breach.

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

@@ -2,6 +2,13 @@
 name: backend-testing
 description: API integration tests, contract testing, database testing patterns, mocking external services, and load testing
 topics: [backend, testing, integration-tests, contract-testing, database-testing, mocking, load-testing]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.pact.io/
+  - url: https://martinfowler.com/articles/practical-test-pyramid.html
+  - url: https://martinfowler.com/bliki/ContractTest.html
 ---
 
 Backend testing strategy determines how much confidence you have before every deploy — a well-layered test suite catches regressions at the fastest possible feedback loop while still exercising the real data layer and honoring API contracts with consumers.

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

@@ -2,6 +2,12 @@
 name: backend-worker-patterns
 description: Background job frameworks, cron scheduling, event consumers, dead letter queues, retry strategies, and graceful shutdown for workers
 topics: [backend, workers, bullmq, celery, temporal, cron, background-jobs, dlq]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://microservices.io/patterns/data/transactional-outbox.html
+  - url: https://sre.google/sre-book/handling-overload/
 ---
 
 Background workers offload time-consuming and deferred work from the request path, but they introduce their own failure modes — jobs that silently vanish, duplicate executions, and unclean shutdowns during deploys all require deliberate design to prevent.

package/content/knowledge/browser-extension/browser-extension-architecture.md

@@ -2,6 +2,12 @@
 name: browser-extension-architecture
 description: Component isolation across content scripts, background service workers, and popup pages; message passing patterns; and state synchronization strategies
 topics: [browser-extension, architecture, message-passing, state-synchronization, service-worker, content-scripts]
+volatility: evolving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/extensions/mv3/architecture-overview
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Anatomy_of_a_WebExtension
 ---
 
 Browser extension architecture is fundamentally different from web app architecture because the application is split across multiple isolated execution environments that cannot share memory directly. Content scripts run inside host pages but in an isolated JavaScript world. Service workers run in a separate context that is terminated and re-created between events. Popup pages are ephemeral — they exist only while the popup is open. These constraints drive every architectural decision: communication is via message passing, state must be externalized to `chrome.storage`, and every component must tolerate being initialized from scratch at any time.

package/content/knowledge/browser-extension/browser-extension-content-scripts.md

@@ -2,6 +2,12 @@
 name: browser-extension-content-scripts
 description: DOM manipulation from content scripts, isolated worlds, CSS injection, and communicating with the host page via postMessage
 topics: [browser-extension, content-scripts, dom-manipulation, isolated-worlds, css-injection, postmessage]
+volatility: fast-moving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts
 ---
 
 Content scripts are the extension's interface with the web page. They run inside the page's DOM but in an isolated JavaScript world — they see the same HTML and can manipulate the same elements, but they cannot access the page's JavaScript variables or prototype chain without explicitly crossing the world boundary. Understanding this isolation is essential for writing content scripts that are both functional and secure.

package/content/knowledge/browser-extension/browser-extension-conventions.md

@@ -2,6 +2,12 @@
 name: browser-extension-conventions
 description: Naming conventions for manifests, message action types, file organization, and i18n structure in browser extensions
 topics: [browser-extension, conventions, naming, i18n, file-organization, messaging]
+volatility: evolving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/extensions/reference/manifest
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization
 ---
 
 Browser extensions accumulate technical debt faster than typical web apps because they span multiple execution contexts — content scripts, service workers, popup pages, options pages — each with distinct constraints. Consistent naming conventions and file organization make cross-context code navigable and reduce the cognitive overhead of working across these boundaries. Establish conventions before writing code.

package/content/knowledge/browser-extension/browser-extension-cross-browser.md

@@ -2,6 +2,12 @@
 name: browser-extension-cross-browser
 description: Using webextension-polyfill for API compatibility, manifest differences between Chrome and Firefox, browser-specific APIs, and managing a multi-browser build matrix
 topics: [browser-extension, cross-browser, firefox, chrome, webextension-polyfill, compatibility, build-matrix]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs
+  - url: https://developer.chrome.com/docs/extensions/develop/migrate
 ---
 
 Browser extensions that target both Chrome and Firefox share most of their codebase, but the differences between the two platforms are significant enough to require explicit management. API namespaces differ, manifest syntax diverges in subtle ways, and some APIs exist only in Chrome or only in Firefox. A systematic cross-browser strategy prevents the "works in Chrome, broken in Firefox" class of bugs.

package/content/knowledge/browser-extension/browser-extension-dev-environment.md

@@ -2,6 +2,12 @@
 name: browser-extension-dev-environment
 description: Build tooling with Webpack/Vite, hot reload via web-ext and crx-hotreload, and browser launch configuration for extension development
 topics: [browser-extension, dev-environment, vite, webpack, hot-reload, web-ext, build]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.chrome.com/docs/extensions/get-started/tutorial/hello-world
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Your_first_WebExtension
 ---
 
 Browser extension development requires a different local setup than web app development. There is no dev server to navigate to — the extension must be loaded into a real browser instance, and changes require either a manual reload or a dedicated hot-reload tool. Getting this setup right at the start of the project eliminates the most friction-heavy part of the development loop.

package/content/knowledge/browser-extension/browser-extension-manifest.md

@@ -2,6 +2,12 @@
 name: browser-extension-manifest
 description: Manifest V3 schema, permissions declarations, host_permissions, content_scripts configuration, and background service_worker setup
 topics: [browser-extension, manifest, manifest-v3, permissions, content-scripts, service-worker, host-permissions]
+volatility: fast-moving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/extensions/reference/manifest
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json
 ---
 
 The `manifest.json` is the contract between your extension and the browser. Every capability your extension uses must be declared here before it can be used. Manifest V3 (MV3) is the current standard, having replaced Manifest V2 (MV2) in Chrome. Understanding the MV3 schema in depth prevents runtime errors, store rejections, and security review failures.

package/content/knowledge/browser-extension/browser-extension-project-structure.md

@@ -2,6 +2,12 @@
 name: browser-extension-project-structure
 description: Directory layout for browser extensions covering src/popup, src/content, src/background, src/options, public/icons, and _locales
 topics: [browser-extension, project-structure, file-organization, build, icons]
+volatility: evolving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/extensions/develop
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Anatomy_of_a_WebExtension
 ---
 
 Browser extension project structure must account for multiple compilation targets (one bundle per execution context), static assets that bypass the build pipeline, and locale files consumed by the WebExtensions runtime. A well-organized project structure makes build configuration straightforward, keeps context-specific code isolated, and prevents accidentally importing browser APIs that are unavailable in a given context.

package/content/knowledge/browser-extension/browser-extension-requirements.md

@@ -2,6 +2,12 @@
 name: browser-extension-requirements
 description: User permissions model, store policies (Chrome Web Store, AMO), accessibility requirements, and performance budgets for browser extensions
 topics: [browser-extension, requirements, permissions, store-policies, accessibility, performance]
+volatility: evolving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/webstore/program-policies
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Policy
 ---
 
 Browser extension requirements differ fundamentally from web app requirements because the extension operates inside a user's browser with elevated trust and broad access to browsing data. Every permission requested must be justified, every store policy must be understood before writing code, and performance budgets must be set early because extensions run on every page a user visits — regressions directly degrade the entire browsing experience.

package/content/knowledge/browser-extension/browser-extension-security.md

@@ -2,6 +2,13 @@
 name: browser-extension-security
 description: Content Security Policy for extensions, prohibitions on eval and inline scripts, host permissions principle of least privilege, and XSS prevention in extension UIs
 topics: [browser-extension, security, csp, xss, permissions, least-privilege, eval]
+volatility: evolving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/extensions/reference/manifest/content-security-policy
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy
+  - url: https://owasp.org/www-community/attacks/xss/
 ---
 
 Browser extensions run with elevated browser privileges compared to ordinary web pages. A compromised extension can read browsing history, intercept network requests, steal cookies, and inject content into any page it has permission to access. Security is not optional — it is a first-class requirement enforced by the browser, the store review process, and the trust of every user who installs the extension.

package/content/knowledge/browser-extension/browser-extension-service-workers.md

@@ -2,6 +2,12 @@
 name: browser-extension-service-workers
 description: Extension service worker lifecycle (install/activate), event-driven programming model, alarms API for recurring tasks, and persistent state via chrome.storage
 topics: [browser-extension, service-worker, lifecycle, alarms, chrome-storage, event-driven, background]
+volatility: fast-moving
+last-reviewed: null
+version-pin: 'Manifest V3'
+sources:
+  - url: https://developer.chrome.com/docs/extensions/develop/concepts/service-workers
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Background_scripts
 ---
 
 The Manifest V3 background service worker is the most architecturally disruptive change from MV2. The persistent background page that could hold state indefinitely is gone. Service workers are event-driven and ephemeral — Chrome terminates them when idle and restarts them when events arrive. Every design decision for background logic must account for this constraint.

package/content/knowledge/browser-extension/browser-extension-store-submission.md

@@ -2,6 +2,12 @@
 name: browser-extension-store-submission
 description: Chrome Web Store review process, AMO submission, screenshot and promotional image requirements, listing optimization, and managing version updates
 topics: [browser-extension, store-submission, chrome-web-store, amo, listing-optimization, review-process, screenshots]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.chrome.com/docs/webstore/publish
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Distribution
 ---
 
 Store submission is the deployment step for browser extensions. Unlike web applications where you push to a server, extensions must pass store review before reaching users. Review timelines, policy requirements, and listing quality directly affect user acquisition and approval success. Understanding the process before writing the first line of code prevents costly late-stage pivots.

package/content/knowledge/browser-extension/browser-extension-testing.md

@@ -2,6 +2,12 @@
 name: browser-extension-testing
 description: Extension testing with Puppeteer and Playwright, unit testing shared logic, and manual cross-browser smoke test procedures
 topics: [browser-extension, testing, puppeteer, playwright, unit-testing, e2e, smoke-tests, cross-browser]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.chrome.com/docs/extensions/how-to/test/end-to-end-testing
+  - url: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Testing_persistent_and_restart_features
 ---
 
 Browser extension testing is harder than web app testing because the extension runs in a privileged browser context that most test frameworks cannot easily access. The strategy is to maximize the code that lives in plain TypeScript (easily unit-tested), minimize the code that requires a real browser to test (expensive), and write targeted end-to-end tests that exercise the extension in a real browser for the scenarios that matter most.

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

@@ -2,6 +2,10 @@
 name: cli-architecture
 description: Command router patterns, plugin systems, middleware chains, config resolution order, and lazy loading for CLI tools
 topics: [cli, architecture, command-router, plugins, middleware, config-resolution, lazy-loading]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 CLI architecture is simpler than web architecture but has its own failure modes: slow startup, monolithic command files that resist extension, config that behaves unpredictably, and plugin systems that become security liabilities. Decisions made at the architecture level — how commands are registered, how config is resolved, how plugins hook in — determine whether the tool remains maintainable as it grows.

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

@@ -2,6 +2,10 @@
 name: cli-conventions
 description: Flag naming, subcommand patterns, help text standards, --version behavior, and NO_COLOR support for CLI tools
 topics: [cli, conventions, flags, subcommands, help-text, no-color, version]
+volatility: stable
+last-reviewed: null
+version-pin: 'POSIX.1-2017'
+sources: []
 ---
 
 CLI conventions exist because shell users build mental models across dozens of tools. When your tool follows the same conventions as `git`, `docker`, and `kubectl`, users already know how to use it before reading the documentation. Deviating from convention has a real cost: every exception must be explicitly learned.

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

@@ -2,6 +2,11 @@
 name: cli-dev-environment
 description: Local development setup for CLIs including npm link, cargo install, debug flags, manual testing workflow, and hot reload
 topics: [cli, dev-environment, npm-link, cargo, debug, hot-reload, testing-workflow]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.astral.sh/uv/
 ---
 
 CLI development has a tighter feedback loop requirement than library development: you need to run the actual binary, observe its output, and verify behavior against real filesystem and network state. Setting up a fast local development workflow is not optional — a slow iteration cycle compounds across hundreds of test invocations.

package/content/knowledge/cli/cli-distribution-patterns.md

@@ -2,6 +2,11 @@
 name: cli-distribution-patterns
 description: npm, pip, and cargo publishing, Homebrew formulae, standalone binaries, Docker images, and GitHub Releases with checksums
 topics: [cli, distribution, npm, homebrew, cargo, pip, standalone-binaries, github-releases, checksums]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://peps.python.org/pep-0621/
 ---
 
 Distribution is where many CLI projects fail: the tool works perfectly in development but is painful to install, update, or run in different environments. A well-distributed CLI reaches users through multiple channels (package manager, direct download, container) and handles updates gracefully.

package/content/knowledge/cli/cli-interactivity-patterns.md

@@ -2,6 +2,10 @@
 name: cli-interactivity-patterns
 description: Prompt libraries, spinners, progress bars, color output, TTY detection, and graceful degradation for piped output
 topics: [cli, interactivity, prompts, spinners, progress-bars, tty-detection, color, chalk]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Interactive CLI features — prompts, spinners, progress bars, colored output — exist to help humans. They must never obstruct machines. The guiding principle is graceful degradation: detect the execution context and silently disable interactive features when they would break automation.

package/content/knowledge/cli/cli-output-patterns.md

@@ -2,6 +2,10 @@
 name: cli-output-patterns
 description: --json/--format flags, table formatting, machine-readable output, piping conventions, and --quiet flag for CLI tools
 topics: [cli, output, json, formatting, tables, piping, stdout, stderr, machine-readable]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 CLI output is a two-audience problem: humans reading in a terminal, and machines reading in a pipeline. Tools that ignore the machine audience force users to write fragile regex parsers against human-formatted output. Tools that ignore the human audience are inscrutable to debug. The solution is structured output modes with a clear default.

package/content/knowledge/cli/cli-project-structure.md

@@ -2,6 +2,10 @@
 name: cli-project-structure
 description: Directory layout, entry points, config file resolution, and plugin directory structure for CLI projects
 topics: [cli, project-structure, directory-layout, config-resolution, bin, plugins]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 A well-structured CLI project makes it easy to add subcommands, locate business logic, and onboard contributors. The structure should reflect the mental model of the tool: commands are the public API, utilities are shared infrastructure, and configuration drives runtime behavior.

package/content/knowledge/cli/cli-requirements.md

@@ -2,6 +2,10 @@
 name: cli-requirements
 description: CLI UX principles, POSIX conventions, exit codes, signal handling, and progressive disclosure for command-line tools
 topics: [cli, ux, posix, exit-codes, signal-handling, progressive-disclosure]
+volatility: stable
+last-reviewed: null
+version-pin: 'POSIX.1-2017'
+sources: []
 ---
 
 CLI tools occupy a unique design space: they are used by humans typing commands, embedded in shell scripts, and piped together in pipelines. A tool that conflates these contexts fails at all of them. The guiding principle is: do one thing well, fail loudly with actionable errors, and never surprise the pipeline.

package/content/knowledge/cli/cli-shell-integration.md

@@ -2,6 +2,10 @@
 name: cli-shell-integration
 description: Shell completion generation for bash/zsh/fish, man page generation, dotfile conventions, PATH management, and shell aliases
 topics: [cli, shell-integration, completion, man-pages, dotfiles, path-management, aliases]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Shell integration is the difference between a CLI that feels native and one that feels like a foreign object. Completion, man pages, and dotfile patterns are not optional polish — they are the features that determine whether power users adopt the tool or abandon it for something that respects their shell workflow.

package/content/knowledge/cli/cli-testing.md

@@ -2,6 +2,10 @@
 name: cli-testing
 description: CLI integration testing by spawning processes, snapshot testing help text, mock filesystem, environment variable testing, and CI matrix testing
 topics: [cli, testing, integration-tests, snapshot-testing, mock-filesystem, ci-matrix, exit-codes]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 CLI testing requires a different mindset than library testing. The contract being tested is behavioral: given this argv and environment, what does the tool write to stdout, what does it write to stderr, and what exit code does it return? Unit tests for business logic are necessary but not sufficient — integration tests that spawn the actual binary catch the class of bugs that only appear at the boundary between argument parsing and execution.

package/content/knowledge/core/adr-craft.md

@@ -2,6 +2,14 @@
 name: adr-craft
 description: Writing effective architecture decision records including technology selection
 topics: [adr, architecture-decisions, tech-stack, decision-documentation, technology-selection]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://adr.github.io/
+    anchor: '#decision-record-templates'
+  - url: https://github.com/joelparkerhenderson/architecture-decision-record
+    anchor: '#adr-templates'
 ---
 
 ## Summary

package/content/knowledge/core/ai-memory-management.md

@@ -2,6 +2,12 @@
 name: ai-memory-management
 description: AI memory and context management patterns for Claude Code projects including modular rules, MCP memory servers, lifecycle hooks, decision logging, and external context integration
 topics: [ai-memory, claude-code, claude-rules, mcp-servers, lifecycle-hooks, context-management, session-handoff, decision-logging, mcp-knowledge-graph, context7]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://modelcontextprotocol.io/specification
+  - url: https://docs.anthropic.com/en/docs/build-with-claude/memory
 ---
 
 # AI Memory Management

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

@@ -2,6 +2,12 @@
 name: api-design
 description: API design principles for REST, GraphQL, and inter-service communication
 topics: [api, rest, graphql, endpoints, contracts, versioning, error-handling, authentication]
+volatility: evolving
+last-reviewed: null
+version-pin: 'OpenAPI 3.1 / GraphQL October 2021'
+sources:
+  - url: https://spec.openapis.org/oas/v3.1.0
+  - url: https://spec.graphql.org/October2021/
 ---
 
 ## Summary

package/content/knowledge/core/automated-review-tooling.md

@@ -2,6 +2,14 @@
 name: automated-review-tooling
 description: Patterns for automated code review using AI CLI tools (Codex, Gemini, Claude) — three-CLI MMR orchestration plus Superpowers 4th channel in wrappers, reconciliation, compensating passes, PR + non-PR targets, and CI integration
 topics: [code-review, automation, codex, gemini, claude, pull-requests, non-pr-review, mmr, ci-cd, review-tooling]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.anthropic.com/en/docs/claude-code/overview
+    anchor: '#claude-code-cli'
+  - url: https://ai.google.dev/gemini-api/docs
+    anchor: '#cli-tools'
 ---
 
 # Automated Review Tooling

package/content/knowledge/core/claude-md-patterns.md

@@ -2,6 +2,14 @@
 name: claude-md-patterns
 description: Patterns for structuring CLAUDE.md files including section organization, rule authoring, pointer patterns, and merge strategies
 topics: [claude-md, ai-configuration, rule-files, memory-management, project-setup]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.anthropic.com/en/docs/claude-code/memory
+    anchor: '#claude-md-files'
+  - url: https://docs.anthropic.com/en/docs/claude-code/settings
+    anchor: '#configuration-precedence'
 ---
 
 # CLAUDE.md Patterns

package/content/knowledge/core/coding-conventions.md

@@ -2,6 +2,14 @@
 name: coding-conventions
 description: Universal coding standards patterns across languages and linter/formatter configuration
 topics: [coding-standards, linting, formatting, naming, error-handling, code-style]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://google.github.io/styleguide/
+    anchor: '#language-style-guides'
+  - url: https://peps.python.org/pep-0008/
+    anchor: '#code-lay-out'
 ---
 
 # Coding Conventions

package/content/knowledge/core/database-design.md

@@ -2,6 +2,14 @@
 name: database-design
 description: Database schema design, normalization, indexing, and migration patterns
 topics: [database, schema, sql, nosql, migrations, indexing, data-modeling]
+volatility: stable
+last-reviewed: null
+version-pin: 'SQL:2023 / PostgreSQL 16'
+sources:
+  - url: https://www.postgresql.org/docs/current/ddl.html
+    anchor: '#data-definition'
+  - url: https://www.iso.org/standard/76583.html
+    anchor: '#sql-2023'
 ---
 
 ## Summary

package/content/knowledge/core/design-system-tokens.md

@@ -2,6 +2,14 @@
 name: design-system-tokens
 description: Design token definitions, base component visual specs, dark mode patterns, and pattern library for building consistent UIs
 topics: [design-system, tokens, colors, typography, spacing, components, dark-mode, pattern-library]
+volatility: evolving
+last-reviewed: null
+version-pin: 'W3C Design Tokens Community Group Draft'
+sources:
+  - url: https://www.w3.org/community/design-tokens/
+    anchor: '#format-module'
+  - url: https://tr.designtokens.org/format/
+    anchor: '#design-token-format'
 ---
 
 ## Summary

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

@@ -2,6 +2,10 @@
 name: dev-environment
 description: Development environment setup patterns including Makefile conventions, live reload, and toolchain configuration
 topics: [dev-environment, makefile, live-reload, env-files, toolchain, ci, git-hooks, scripts]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Dev Environment

package/content/knowledge/core/domain-modeling.md

@@ -2,6 +2,12 @@
 name: domain-modeling
 description: Domain-driven design patterns for identifying and modeling project domains
 topics: [ddd, domain-modeling, entities, aggregates, bounded-contexts, domain-events, value-objects]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/bliki/BoundedContext.html
+  - url: https://martinfowler.com/bliki/DDD_Aggregate.html
 ---
 
 ## Summary

package/content/knowledge/core/eval-craft.md

@@ -2,6 +2,12 @@
 name: eval-craft
 description: Writing effective project evals that verify AI-generated code meets documented standards
 topics: [evals, verification, coverage, adherence, consistency, structure, code-quality, standards-compliance]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.anthropic.com/en/docs/test-and-evaluate/eval-tool
+    anchor: '#evaluation-tool'
 ---
 
 # Eval Craft

package/content/knowledge/core/git-workflow-patterns.md

@@ -2,6 +2,14 @@
 name: git-workflow-patterns
 description: Git branching strategies, commit conventions, PR workflows, merge policies, and CI integration patterns for AI-agent-driven development
 topics: [git, branching, commits, pull-requests, ci-cd, merge-strategy, worktrees]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://git-scm.com/docs/git-worktree
+    anchor: '#_description'
+  - url: https://www.conventionalcommits.org/en/v1.0.0/
+    anchor: '#specification'
 ---
 
 # Git Workflow Patterns

package/content/knowledge/core/multi-model-research-dispatch.md

@@ -2,6 +2,12 @@
 name: multi-model-research-dispatch
 description: Patterns for dispatching research and adversarial challenge to external AI models (Codex, Gemini) with reconciliation rules and single-model fallback
 topics: [multi-model, research, competitive-analysis, red-team, codex, gemini, dispatch, reconciliation]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://ai.google.dev/gemini-api/docs
+  - url: https://docs.anthropic.com/en/docs/claude-code/cli-reference
 ---
 
 # Multi-Model Research Dispatch

package/content/knowledge/core/multi-model-review-dispatch.md

@@ -2,6 +2,12 @@
 name: multi-model-review-dispatch
 description: Patterns for dispatching reviews to AI CLI tools (Codex, Gemini, Claude), including fallback strategies and finding reconciliation
 topics: [multi-model, code-review, codex, gemini, claude, review-synthesis]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://ai.google.dev/gemini-api/docs
+  - url: https://docs.anthropic.com/en/docs/claude-code/cli-reference
 ---
 
 # Multi-Model Review Dispatch

package/content/knowledge/core/multi-service-api-contracts.md

@@ -2,6 +2,11 @@
 name: multi-service-api-contracts
 description: Internal API versioning, backward compatibility, retries, and idempotency patterns
 topics: [internal-api-versioning, backward-compatibility, retries, idempotency, contract-evolution]
+volatility: evolving
+last-reviewed: null
+version-pin: 'RFC 9110'
+sources:
+  - url: https://www.rfc-editor.org/rfc/rfc9110
 ---
 
 ## Summary