@zigrivers/scaffold 3.28.0 → 3.30.0

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

package/content/knowledge/core/multi-service-architecture.md

@@ -2,6 +2,11 @@
 name: multi-service-architecture
 description: Service boundary design, communication patterns, service discovery, and networking topology
 topics: [service-boundaries, communication-patterns, service-discovery, networking-topology, data-ownership, sync-vs-async]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html
 ---
 
 ## Summary

package/content/knowledge/core/multi-service-auth.md

@@ -2,6 +2,12 @@
 name: multi-service-auth
 description: Mutual TLS, service tokens, zero-trust architecture, and audience scoping
 topics: [mtls, service-tokens, zero-trust, audience-scoping, token-rotation]
+volatility: evolving
+last-reviewed: null
+version-pin: 'RFC 6749 / OIDC Core 1.0'
+sources:
+  - url: https://www.rfc-editor.org/rfc/rfc6749
+  - url: https://openid.net/specs/openid-connect-core-1_0.html
 ---
 
 ## Summary

package/content/knowledge/core/multi-service-data-ownership.md

@@ -2,6 +2,14 @@
 name: multi-service-data-ownership
 description: Table ownership, shared-nothing data patterns, and event-driven synchronization
 topics: [table-ownership, shared-nothing, event-driven-sync, data-partitioning, eventual-consistency]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/articles/microservices.html
+    anchor: '#DecentralizedDataManagement'
+  - url: https://microservices.io/patterns/data/database-per-service.html
+    anchor: '#solution'
 ---
 
 ## Summary

package/content/knowledge/core/multi-service-observability.md

@@ -2,6 +2,14 @@
 name: multi-service-observability
 description: Distributed tracing, correlation IDs, cross-service SLOs, and failure attribution
 topics: [distributed-tracing, correlation-ids, cross-service-slos, failure-attribution]
+volatility: evolving
+last-reviewed: null
+version-pin: 'OpenTelemetry 1.x'
+sources:
+  - url: https://opentelemetry.io/docs/specs/otel/
+    anchor: '#overview'
+  - url: https://www.w3.org/TR/trace-context/
+    anchor: '#traceparent-header'
 ---
 
 ## Summary

package/content/knowledge/core/multi-service-resilience.md

@@ -2,6 +2,11 @@
 name: multi-service-resilience
 description: Circuit breakers, bulkheads, timeout budgets, and failure isolation strategies
 topics: [circuit-breakers, bulkheads, timeout-budgets, failure-isolation, retry-storms]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
 ---
 
 ## Summary

package/content/knowledge/core/multi-service-task-decomposition.md

@@ -2,6 +2,14 @@
 name: multi-service-task-decomposition
 description: Breaking multi-service work into per-service implementation waves
 topics: [per-service-waves, dependency-ordering, parallel-implementation, shared-infrastructure-first]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://martinfowler.com/articles/microservices.html
+    anchor: '#OrganizedAroundBusinessCapabilities'
+  - url: https://microservices.io/patterns/decomposition/decompose-by-business-capability.html
+    anchor: '#solution'
 ---
 
 ## Summary

package/content/knowledge/core/multi-service-testing.md

@@ -2,6 +2,11 @@
 name: multi-service-testing
 description: Consumer-driven contract testing, cross-service E2E strategies, and service test doubles
 topics: [contract-tests, pact, schema-registry, cross-service-e2e, test-doubles]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.pact.io/
 ---
 
 ## Summary

package/content/knowledge/core/operations-runbook.md

@@ -2,6 +2,14 @@
 name: operations-runbook
 description: Deployment pipeline, deployment strategies, monitoring, alerting, and incident response
 topics: [operations, ci-cd, deployment, monitoring, incident-response, alerting, rollback]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://sre.google/sre-book/table-of-contents/
+    anchor: '#part-iii-practices'
+  - url: https://sre.google/workbook/table-of-contents/
+    anchor: '#incident-response'
 ---
 
 ## Summary

package/content/knowledge/core/project-structure-patterns.md

@@ -2,6 +2,10 @@
 name: project-structure-patterns
 description: Directory layout patterns by framework, module organization, and file placement rules
 topics: [project-structure, directory-layout, module-organization, file-placement, monorepo, colocation]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Project Structure Patterns

package/content/knowledge/core/review-step-template.md

@@ -2,6 +2,10 @@
 name: review-step-template
 description: Shared template pattern for review pipeline steps including multi-model dispatch, finding severity, and resolution workflow
 topics: [review, template, multi-model, quality-gates, methodology]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review Step Template