@zigrivers/scaffold 3.28.0 → 3.30.0

package/content/knowledge/mobile-app/mobile-app-conventions.md

@@ -2,6 +2,12 @@
 name: mobile-app-conventions
 description: Platform naming conventions, accessibility patterns, navigation patterns, and code style for iOS and Android mobile apps
 topics: [mobile-app, conventions, swift, kotlin, naming, accessibility, navigation]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/design/human-interface-guidelines
+  - url: https://developer.android.com/design
 ---
 
 Mobile platform conventions exist for consistency across the ecosystem, toolchain compatibility, and team readability. iOS and Android have distinct naming conventions, navigation paradigms, and accessibility implementation patterns. Mixing conventions or importing web/backend naming styles into mobile code creates cognitive friction and breaks tooling assumptions (SwiftUI previews, Android Studio refactoring, lint rules).

package/content/knowledge/mobile-app/mobile-app-deployment.md

@@ -2,6 +2,12 @@
 name: mobile-app-deployment
 description: App store submission, code signing, provisioning profiles, CI/CD with Fastlane, and release management for iOS and Android
 topics: [mobile-app, deployment, app-store, google-play, code-signing, fastlane, ci-cd, release-management]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/app-store/review/guidelines/
+  - url: https://developer.android.com/studio/publish
 ---
 
 Mobile app deployment is significantly more complex than web deployment: code signing creates a cryptographic chain of trust, app store review is a human process with 24–48 hour latency, and binary deployment means bugs cannot be hot-patched without a full submission cycle. Automate as much of this as possible with Fastlane — manual signing and upload processes are error-prone and do not scale to frequent releases.

package/content/knowledge/mobile-app/mobile-app-dev-environment.md

@@ -2,6 +2,12 @@
 name: mobile-app-dev-environment
 description: Simulator and emulator setup, physical device testing, hot reload, debugging tools, and developer toolchain for iOS and Android
 topics: [mobile-app, dev-environment, simulator, emulator, debugging, xcode, android-studio, hot-reload]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/xcode
+  - url: https://developer.android.com/studio/intro
 ---
 
 Mobile development environments are significantly more complex than web development: two IDEs, two simulators, hardware-specific debugging, code signing requirements, and platform SDK updates that break builds. A well-configured dev environment reduces friction by 50% — standardize tool versions, automate simulator setup, and document the steps from clean machine to first successful build.

package/content/knowledge/mobile-app/mobile-app-distribution.md

@@ -2,6 +2,12 @@
 name: mobile-app-distribution
 description: TestFlight and Google Play internal track, enterprise MDM distribution, staged rollouts, beta testing programs, and OTA updates for mobile apps
 topics: [mobile-app, distribution, testflight, google-play, enterprise-mdm, staged-rollout, beta-testing, ota]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/testflight/
+  - url: https://developer.android.com/distribute
 ---
 
 Mobile app distribution has more complexity than web deployment: app store review introduces unpredictable latency, staged rollouts require monitoring and rollback planning, enterprise distribution requires MDM infrastructure, and React Native/Expo apps have limited OTA update options for business logic. Design the distribution pipeline before writing code — it affects app architecture (feature flags, forced update logic) and CI/CD setup.

package/content/knowledge/mobile-app/mobile-app-observability.md

@@ -2,6 +2,13 @@
 name: mobile-app-observability
 description: Crash reporting (Crashlytics/Sentry), analytics, performance monitoring, network tracing, and structured logging for mobile apps
 topics: [mobile-app, observability, crashlytics, sentry, analytics, performance-monitoring, network-tracing, logging]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://opentelemetry.io/docs/
+  - url: https://developer.apple.com/documentation/metrickit
+  - url: https://developer.android.com/topic/performance
 ---
 
 Mobile observability is harder than server observability: you cannot SSH into a user's phone, crashes happen on thousands of device/OS combinations you cannot reproduce locally, and performance issues manifest differently across network conditions and hardware tiers. The goal is to know about problems before users report them, understand why they occurred, and have enough context to reproduce and fix them.

package/content/knowledge/mobile-app/mobile-app-offline-patterns.md

@@ -2,6 +2,13 @@
 name: mobile-app-offline-patterns
 description: Local storage (SQLite/Room/Core Data), sync engines, conflict resolution, and background sync for offline-capable mobile apps
 topics: [mobile-app, offline, sqlite, room, core-data, sync, conflict-resolution, background-sync]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/coredata
+  - url: https://developer.android.com/training/data-storage/room
+  - url: https://developer.android.com/topic/libraries/architecture/workmanager
 ---
 
 Offline capability is not optional for mobile apps — cellular networks are unreliable, users enter tunnels and basements, and users expect their data to persist between sessions. The complexity of offline architecture scales with sync complexity: read-only cache is trivial; bidirectional sync with conflict resolution is one of the hardest problems in software. Define your offline model explicitly before implementing persistence.

package/content/knowledge/mobile-app/mobile-app-project-structure.md

@@ -2,6 +2,12 @@
 name: mobile-app-project-structure
 description: Platform directory layout, shared code modules, asset management, and per-environment configuration for iOS and Android mobile apps
 topics: [mobile-app, project-structure, ios, android, assets, configuration, modules]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/xcode/managing-files-and-folders-in-your-xcode-project
+  - url: https://developer.android.com/studio/projects
 ---
 
 Mobile project structure decisions affect build times, code sharing, onboarding velocity, and refactoring safety. iOS and Android have platform-mandated directory conventions that tools expect — deviating from them breaks Xcode file resolution, Android Gradle source sets, and code-generation tooling. Within those constraints, module boundaries and shared-code strategies deserve explicit design.

package/content/knowledge/mobile-app/mobile-app-push-notifications.md

@@ -2,6 +2,12 @@
 name: mobile-app-push-notifications
 description: APNs and FCM setup, notification channels, rich notifications, background handling, and permission best practices for mobile apps
 topics: [mobile-app, push-notifications, apns, fcm, firebase, notification-channels, rich-notifications, background]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/usernotifications
+  - url: https://developer.android.com/develop/ui/views/notifications
 ---
 
 Push notifications are a direct channel to re-engage users, but they are also the fastest way to lose them: irrelevant or excessive notifications get disabled or trigger uninstalls. The technical implementation requires setting up APNs (Apple Push Notification service) for iOS and FCM (Firebase Cloud Messaging) for Android, managing device tokens, and handling notifications in all app states (foreground, background, terminated). Get the permission request timing right — it determines your opt-in rate.

package/content/knowledge/mobile-app/mobile-app-requirements.md

@@ -2,6 +2,13 @@
 name: mobile-app-requirements
 description: Platform guidelines (Apple HIG, Material Design), performance budgets, device matrix, and accessibility requirements for mobile apps
 topics: [mobile-app, requirements, hig, material-design, accessibility, performance, device-matrix]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/design/human-interface-guidelines
+  - url: https://developer.android.com/design
+  - url: https://www.w3.org/WAI/standards-guidelines/wcag/
 ---
 
 Mobile app requirements differ fundamentally from web requirements: platform guidelines are design law, not suggestions; performance budgets are stricter because CPU and battery are finite; accessibility is both a legal obligation and a market expansion. Define all of these explicitly before writing code — changing navigation patterns or accessibility models mid-project is expensive.

package/content/knowledge/mobile-app/mobile-app-security.md

@@ -2,6 +2,14 @@
 name: mobile-app-security
 description: Secure storage (Keychain/Keystore), certificate pinning, biometric authentication, jailbreak/root detection, and data protection for mobile apps
 topics: [mobile-app, security, keychain, keystore, certificate-pinning, biometrics, jailbreak-detection, data-protection]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/www-project-mobile-top-10/
+  - url: https://owasp.org/www-project-mobile-app-security/
+  - url: https://developer.apple.com/documentation/security/keychain_services
+  - url: https://developer.android.com/privacy-and-security/keystore
 ---
 
 Mobile apps operate in an adversarial environment: devices are lost or stolen, users jailbreak/root their devices, and network traffic is subject to interception. Security must be designed in, not bolted on. The most common mobile security failures are storing secrets in plaintext, trusting all TLS certificates (or disabling certificate validation), and failing to protect data at rest. Implement defense in depth — assume any single control will fail.

package/content/knowledge/mobile-app/mobile-app-testing.md

@@ -2,6 +2,12 @@
 name: mobile-app-testing
 description: Unit tests, UI tests (XCTest/Espresso/Detox), snapshot tests, accessibility testing, and test architecture for iOS and Android
 topics: [mobile-app, testing, xctest, espresso, detox, snapshot-testing, accessibility-testing, unit-tests]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://developer.apple.com/documentation/xctest
+  - url: https://developer.android.com/training/testing
 ---
 
 Mobile testing requires a multi-layer strategy: unit tests for business logic, integration tests for repository and network layers, UI tests for critical user flows, and snapshot tests for visual regression. The test pyramid applies — fast unit tests outnumber slow UI tests. Mobile UI tests are inherently fragile (timing, simulator state, animations) — structure them to minimize flakiness and run only the highest-value flows in CI.

package/content/knowledge/product/gap-analysis.md

@@ -2,6 +2,10 @@
 name: gap-analysis
 description: Systematic approaches to finding gaps in requirements and specifications
 topics: [gap-analysis, requirements, completeness, ambiguity, edge-cases]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Gap Analysis

package/content/knowledge/product/ideation-craft.md

@@ -2,6 +2,10 @@
 name: ideation-craft
 description: Questioning techniques, research methodology, lightweight expansion patterns, and brief synthesis for early-stage idea exploration
 topics: [ideation, questioning, research, competitive-analysis, brief-synthesis, socratic-method]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Ideation Craft

package/content/knowledge/product/prd-craft.md

@@ -2,6 +2,10 @@
 name: prd-craft
 description: What makes a good PRD — problem framing, feature scoping, success criteria, competitive context
 topics: [prd, requirements, product, scoping]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # PRD Craft

package/content/knowledge/product/prd-innovation.md

@@ -2,6 +2,10 @@
 name: prd-innovation
 description: Techniques for discovering feature-level innovation opportunities in product requirements
 topics: [innovation, prd, competitive-analysis, product-thinking, features]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # PRD Innovation

package/content/knowledge/product/vision-craft.md

@@ -2,6 +2,10 @@
 name: vision-craft
 description: What makes a good product vision — strategic framing, audience definition, competitive positioning, guiding principles
 topics: [vision, strategy, product, positioning, competitive-analysis]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Vision Craft

package/content/knowledge/product/vision-innovation.md

@@ -2,6 +2,10 @@
 name: vision-innovation
 description: Techniques for discovering strategic innovation opportunities in product vision
 topics: [innovation, vision, strategy, competitive-positioning, ecosystem, market-opportunities]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Vision Innovation

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

@@ -2,6 +2,10 @@
 name: research-architecture
 description: Experiment runner architecture including pluggable experiment and evaluation interfaces, state management patterns, and result persistence
 topics: [research, architecture, experiment-runner, state-management, interfaces, persistence]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 The experiment runner is the central architectural component of a research project. It orchestrates the loop of loading configuration, executing experiments, evaluating results, and deciding whether to keep or discard each run. The runner must be completely decoupled from the specific experiment logic (strategies, models, parameter spaces) so that it can drive any experiment without modification. This separation is what makes autonomous iteration possible -- the agent modifies experiment code while the runner infrastructure remains stable.

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

@@ -2,6 +2,12 @@
 name: research-conventions
 description: Coding conventions for research projects including experiment branching, result naming, config management, and reproducibility standards
 topics: [research, conventions, git, branching, reproducibility, config-management]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/reproducible-research/reproducible-research.html
+  - url: https://git-scm.com/docs
 ---
 
 Research code has a unique lifecycle: most code is written to be tried and discarded. A trading strategy that underperforms is reverted. A hyperparameter sweep that converges to a local minimum is abandoned. The conventions must make this try-and-discard cycle fast and safe while preserving a complete audit trail of what was tried and why it was kept or discarded.

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

@@ -2,6 +2,12 @@
 name: research-dev-environment
 description: Development tooling for research projects including virtual environments, dependency management, GPU setup, and data access configuration
 topics: [research, dev-environment, dependencies, virtual-env, gpu, data-access, tooling]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.astral.sh/uv/
+  - url: https://the-turing-way.netlify.app/reproducible-research/renv.html
 ---
 
 Research dev environments have stricter reproducibility requirements than typical application development. A trading strategy that produces different results on a different machine is useless -- the environment itself is a variable that must be controlled. At the same time, research environments need flexibility for rapid iteration: installing new packages, switching between CPU and GPU, and accessing large datasets must be frictionless.

package/content/knowledge/research/research-experiment-loop.md

@@ -2,6 +2,10 @@
 name: research-experiment-loop
 description: Autonomous experiment loop patterns including hypothesis-execute-evaluate-keep/discard cycle, iteration control, budget management, and early stopping
 topics: [research, experiment-loop, autonomous, iteration, budget, early-stopping, hypothesis]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 The experiment loop is the defining pattern of research projects: an agent iteratively generates hypotheses, executes experiments, evaluates results, and makes keep/discard decisions. This loop can run autonomously (agent decides everything), with checkpoints (agent pauses for human review at intervals), or human-guided (human decides what to try, agent executes). The loop's correctness depends on proper iteration control, budget enforcement, and state management -- without these, autonomous agents will iterate forever or lose track of what has been tried.

package/content/knowledge/research/research-experiment-tracking.md

@@ -2,6 +2,12 @@
 name: research-experiment-tracking
 description: Experiment results logging including structured result formats, run comparison, reproducibility tracking, and artifact management
 topics: [research, experiment-tracking, results, comparison, reproducibility, artifacts, mlflow]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://mlflow.org/docs/latest/index.html
+  - url: https://the-turing-way.netlify.app/reproducible-research/reproducible-research.html
 ---
 
 Experiment tracking is the difference between research and random exploration. Without structured logging of what was tried, what resulted, and what was decided, a research project becomes impossible to audit, reproduce, or learn from. Tracking must capture the full context of every run: the exact config, the environment, the metrics, and the keep/discard decision with its rationale.

package/content/knowledge/research/research-ml-architecture-search.md

@@ -2,6 +2,10 @@
 name: research-ml-architecture-search
 description: Neural Architecture Search patterns including search space definition, search strategies, mutation operators, performance prediction, and multi-objective optimization
 topics: [research, ml-research, nas, architecture-search, search-space, evolutionary, darts, surrogate-model, multi-objective]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Neural Architecture Search (NAS) automates the discovery of model architectures that outperform hand-designed ones. The core challenge is navigating an exponentially large search space efficiently -- evaluating every candidate is infeasible, so search strategies must balance exploration (trying diverse architectures) with exploitation (refining promising ones). A well-designed NAS pipeline defines the search space precisely, applies an appropriate search strategy, uses performance prediction to avoid wasting compute on bad candidates, and manages the total search budget to stay within resource constraints.

package/content/knowledge/research/research-ml-evaluation.md

@@ -2,6 +2,10 @@
 name: research-ml-evaluation
 description: Research evaluation patterns including ablation studies, statistical significance testing, multiple comparison correction, effect sizes, learning curve analysis, and efficiency frontiers
 topics: [research, ml-research, evaluation, ablation, significance, bootstrap, bonferroni, effect-size, learning-curve, pareto]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Research evaluation differs fundamentally from production ML evaluation. In production, you measure a single model on held-out data and report aggregate metrics. In research, you compare multiple methods, ablate components to understand contributions, test whether differences are statistically significant rather than due to random variation, and characterize the efficiency frontier (what accuracy is achievable at what compute cost). Reporting a number without confidence intervals, without significance testing against baselines, and without ablations is not research evaluation -- it is anecdote.

package/content/knowledge/research/research-ml-experiment-tracking.md

@@ -2,6 +2,12 @@
 name: research-ml-experiment-tracking
 description: Lightweight experiment tracking for ML research including W&B and MLflow integration, experiment tagging, parallel coordinate plots, run comparison dashboards, and checkpoint strategies
 topics: [research, ml-research, experiment-tracking, wandb, mlflow, parallel-coordinates, checkpointing, comparison, tagging]
+volatility: fast-moving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://docs.wandb.ai/
+  - url: https://mlflow.org/docs/latest/index.html
 ---
 
 ML research experiment tracking prioritizes rapid iteration and comparison over production-grade audit trails. The goal is to answer "which of my 200 runs was best and why?" within seconds, not to maintain a production model registry. This means lightweight setup (local or cloud-hosted, not self-managed infrastructure), aggressive tagging and grouping for filtering, visualization tools that reveal patterns across many runs simultaneously, and checkpoint strategies that keep what matters and discard the rest to avoid filling storage with abandoned experiments.

package/content/knowledge/research/research-ml-training-patterns.md

@@ -2,6 +2,10 @@
 name: research-ml-training-patterns
 description: Training loop patterns for research iteration including fast-fail detection, curriculum exploration, hyperparameter-conditioned training, reproducibility seeding, and checkpoint warm-starting
 topics: [research, ml-research, training, fast-fail, curriculum, hyperparameter, reproducibility, checkpoint, warm-start]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Research training differs fundamentally from production training. In production, you train one model to convergence and ship it. In research, you train hundreds or thousands of configurations, most of which will fail -- the goal is to identify failures as early as possible and invest compute only in promising directions. A well-designed research training loop detects bad configurations within the first few percent of training, supports curriculum and schedule exploration without code changes, enables warm-starting from checkpoints to avoid redundant computation, and guarantees reproducibility so that any promising result can be verified.

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

@@ -2,6 +2,11 @@
 name: research-observability
 description: Monitoring experiment loops including anomaly detection, resource tracking, progress dashboards, and alert thresholds for research projects
 topics: [research, observability, monitoring, anomaly-detection, resource-tracking, dashboards, alerts]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://opentelemetry.io/docs/
 ---
 
 Autonomous experiment loops can run for hours or days without human attention. Without observability, a loop can waste compute on a converged metric, silently produce garbage after a data pipeline failure, or exhaust disk space without anyone noticing. Observability for research is not about uptime SLAs -- it is about experiment health: is the loop making progress, are the results valid, and are resources being consumed at a reasonable rate.

package/content/knowledge/research/research-overfitting-prevention.md

@@ -2,6 +2,11 @@
 name: research-overfitting-prevention
 description: Out-of-sample validation, cross-validation strategies, statistical significance testing, and when to stop iterating to prevent overfitting
 topics: [research, overfitting, validation, cross-validation, statistical-significance, out-of-sample]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/reproducible-research/reproducible-research.html
 ---
 
 Overfitting is the central risk of iterative research. Every time an agent evaluates a hypothesis against data and uses the result to guide the next hypothesis, it is implicitly fitting to that data. After hundreds of iterations, even random strategies will appear to perform well on the evaluation set -- this is multiple comparisons bias. Preventing overfitting requires rigorous separation of training and evaluation data, statistical significance testing, and disciplined stopping criteria.

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

@@ -2,6 +2,11 @@
 name: research-project-structure
 description: Directory structure for research projects including src, experiments, results, configs, data, and notebooks organization
 topics: [research, project-structure, directory-layout, organization]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/project-design/project-design.html
 ---
 
 Research projects have a dual structure that traditional software projects do not: a stable infrastructure layer (the experiment runner, evaluation framework, and data pipeline) and a volatile experiment layer (strategies, models, configs, and results) that changes with every iteration. The directory structure must make this distinction explicit so that the experiment loop can modify volatile files without risk of corrupting the infrastructure.

package/content/knowledge/research/research-quant-backtesting.md

@@ -2,6 +2,10 @@
 name: research-quant-backtesting
 description: Backtesting methodology including walk-forward analysis, look-ahead bias prevention, survivorship bias, transaction cost modeling, and engine architecture
 topics: [research, quant-finance, backtesting, walk-forward, look-ahead-bias, survivorship-bias, transaction-costs, validation]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Backtesting is the core evaluation mechanism in quantitative finance research. A backtest simulates how a strategy would have performed on historical data, but the gap between a backtest and live trading is enormous. Every design decision in the backtesting engine -- how fills are modeled, whether future data leaks into past decisions, how the instrument universe is constructed, how transaction costs are estimated -- determines whether the results are meaningful or self-deceptive. The primary goal of backtesting infrastructure is not to produce impressive returns but to produce honest results that predict live performance.

package/content/knowledge/research/research-quant-market-data.md

@@ -2,6 +2,10 @@
 name: research-quant-market-data
 description: Market data sourcing including OHLCV providers, tick data, corporate actions handling, data quality checks, gap handling, and timezone normalization
 topics: [research, quant-finance, market-data, ohlcv, tick-data, corporate-actions, data-quality, alternative-data]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Market data is the foundation of every quantitative strategy. Bad data produces bad backtests, and bad backtests produce strategies that fail in production. The data pipeline must handle multiple source providers with different conventions, normalize timestamps across timezones, adjust prices for corporate actions (splits, dividends, mergers), detect and fill gaps, and validate quality before any data reaches the strategy. Data quality issues are the most common source of phantom alpha -- apparent returns that disappear when data errors are fixed.

package/content/knowledge/research/research-quant-metrics.md

@@ -2,6 +2,10 @@
 name: research-quant-metrics
 description: Quantitative performance metrics including Sharpe ratio, Sortino ratio, Calmar ratio, maximum drawdown, profit factor, win rate, expectancy, and alpha/beta decomposition
 topics: [research, quant-finance, metrics, sharpe, sortino, calmar, drawdown, profit-factor, information-ratio, alpha, beta]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Performance metrics are the lens through which every trading strategy is evaluated. A single metric is never sufficient -- strategies must be assessed across multiple dimensions including risk-adjusted return, tail risk, consistency, and independence from market direction. The choice of which metric to optimize (primary target) versus which to constrain (guardrails) is a fundamental research design decision. Optimizing the wrong metric or ignoring important dimensions leads to strategies that look good on paper but blow up in practice.

package/content/knowledge/research/research-quant-requirements.md

@@ -2,6 +2,10 @@
 name: research-quant-requirements
 description: Trading system research requirements including strategy hypothesis definition, market regime assumptions, risk budgets, data requirements, and performance targets
 topics: [research, quant-finance, requirements, hypothesis, risk-budget, performance-targets, validation]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Trading strategy research requires requirements that go far beyond "find a profitable strategy." Every research project must define the strategy hypothesis with falsifiable predictions, declare market regime assumptions that bound the strategy's expected operating environment, establish risk budgets that constrain position sizing and drawdown limits, specify data requirements including quality standards and survivorship-bias-free universes, set performance targets with statistical significance thresholds, and mandate out-of-sample validation protocols. Without these constraints, a backtest will always find something that looks good on historical data -- the question is whether it will survive contact with live markets.

package/content/knowledge/research/research-quant-risk.md

@@ -2,6 +2,10 @@
 name: research-quant-risk
 description: Risk management for trading research including regime detection, tail risk measures, correlation breakdown, position limits, drawdown controls, and kill switches
 topics: [research, quant-finance, risk, regime-detection, tail-risk, var, cvar, correlation, drawdown-controls, kill-switch]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Risk management in quantitative finance is not an afterthought bolted onto a profitable strategy -- it is the primary constraint that determines whether a strategy survives long enough to realize its edge. Markets exhibit non-stationary behavior: correlations spike during crises, volatility clusters in ways that violate normal distribution assumptions, and tail events occur far more frequently than Gaussian models predict. A strategy without regime awareness, tail risk measurement, position limits, and automated kill switches is not a strategy -- it is a gamble.

package/content/knowledge/research/research-quant-strategy-patterns.md

@@ -2,6 +2,10 @@
 name: research-quant-strategy-patterns
 description: Trading strategy patterns including signal generation, entry/exit rules, position sizing methods, stop-loss patterns, and multi-asset allocation
 topics: [research, quant-finance, strategy, signals, position-sizing, kelly-criterion, stop-loss, allocation, volatility-targeting]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Trading strategies are composed of discrete building blocks that can be mixed, matched, and tested independently: signal generation (what to trade and when), entry/exit rules (how to initiate and close positions), position sizing (how much capital to allocate), and stop-loss management (how to limit downside). Treating each block as a separate, testable component enables systematic exploration of the strategy design space. Resist the temptation to build monolithic strategies -- instead, compose simple, well-tested components.

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

@@ -2,6 +2,11 @@
 name: research-requirements
 description: Research project requirements including experiment goals, success metrics, iteration budgets, stopping criteria, and hypothesis documentation
 topics: [research, requirements, experiment-goals, metrics, stopping-criteria, hypothesis]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/project-design/project-design.html
 ---
 
 Research projects differ from product engineering in a fundamental way: the requirements are not a list of features to build but a set of questions to answer. A research PRD defines the hypothesis space, the metrics that will determine success or failure, the computational and time budgets for exploration, and the stopping criteria that prevent infinite iteration. Without these constraints, autonomous experiment loops run forever and produce nothing actionable.

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

@@ -2,6 +2,11 @@
 name: research-security
 description: Security for autonomous research agents including sandboxing experiment execution, resource limits, credential isolation, and code injection prevention
 topics: [research, security, sandboxing, resource-limits, credentials, code-injection, autonomous-agents]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://owasp.org/www-project-top-ten/
 ---
 
 Autonomous research agents run code, modify files, and access data without human oversight during each iteration. This creates a security surface that traditional software projects do not have: the agent can accidentally run destructive operations, consume unbounded resources, leak credentials through experiment outputs, or produce code that introduces injection vulnerabilities. Security must be enforced at the infrastructure level -- relying on the agent to "be careful" is not a security strategy.

package/content/knowledge/research/research-sim-compute-management.md

@@ -2,6 +2,10 @@
 name: research-sim-compute-management
 description: Compute resource management for simulations including wall-clock budgets, job scheduling with SLURM and PBS, parallelization strategies, checkpoint/restart for long simulations, resource monitoring, and cost estimation
 topics: [research, simulation, compute-management, slurm, pbs, parallelization, checkpoint-restart, resource-monitoring, cost-estimation, hpc, wall-clock-budget]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Simulation-based research consumes significant compute resources -- a single CFD run can take hours, and parameter sweeps multiply that by hundreds or thousands of evaluations. Effective compute management determines whether a research budget yields 50 useful results or 500. The key challenges are: allocating wall-clock budgets across the experiment campaign, scheduling jobs efficiently on shared HPC resources, choosing the right parallelization level (across parameters vs within simulations), implementing checkpoint/restart for runs that exceed time limits, and monitoring resource usage to prevent waste.

package/content/knowledge/research/research-sim-engine-patterns.md

@@ -2,6 +2,10 @@
 name: research-sim-engine-patterns
 description: Simulation engine integration patterns including wrapping solvers as callable experiments, configuration management, mesh handling, batch job submission, and result parsing
 topics: [research, simulation, engine-integration, openfoam, fenics, simpy, solver-configuration, mesh-management, batch-jobs, result-parsing]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Simulation engines (OpenFOAM, FEniCS, SimPy, COMSOL, Ansys) are typically standalone tools with their own input/output formats, solver configurations, and execution models. Wrapping them as callable experiments requires a uniform interface that abstracts engine-specific details while preserving access to solver parameters that matter for optimization. The key design challenge is creating a thin adapter layer that makes any simulation engine look like a function from parameters to results, without hiding failure modes or losing important solver diagnostics.

package/content/knowledge/research/research-sim-parameter-spaces.md

@@ -2,6 +2,10 @@
 name: research-sim-parameter-spaces
 description: Parameter space definition for simulations including continuous, discrete, and categorical dimensions, Latin Hypercube Sampling, Sobol sequences, interaction effect detection, and sensitivity analysis methods
 topics: [research, simulation, parameter-space, latin-hypercube, sobol-sequences, sensitivity-analysis, morris-method, sobol-indices, dimensionality-reduction, design-of-experiments]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Simulation parameter spaces define the landscape an optimizer must navigate. Unlike ML hyperparameter tuning where evaluations take seconds, simulation evaluations can take hours or days, making efficient space exploration critical. The challenge is threefold: define the space correctly (capturing interactions and constraints between parameters), sample it efficiently (maximizing information per simulation run), and analyze which dimensions actually matter (sensitivity analysis) to reduce the effective dimensionality before expensive optimization.

package/content/knowledge/research/research-sim-validation.md

@@ -2,6 +2,10 @@
 name: research-sim-validation
 description: Simulation validation methodology including comparison against analytical solutions, mesh independence studies, convergence testing, Richardson extrapolation, uncertainty quantification, and the verification vs validation distinction
 topics: [research, simulation, validation, verification, mesh-independence, convergence, richardson-extrapolation, uncertainty-quantification, analytical-solutions, mms]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 Simulation validation answers the fundamental question: does this simulation represent reality? Verification asks a different question: does the code correctly solve the mathematical model? Both are essential -- a perfectly verified code solving the wrong equations is useless, and an unverified code matching experiments might be right for the wrong reasons. The validation pipeline establishes trust in simulation results by systematically comparing against known solutions, demonstrating grid independence, quantifying numerical uncertainty, and documenting the conditions under which the simulation is reliable.

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

@@ -2,6 +2,11 @@
 name: research-testing
 description: Testing experiment loops including determinism tests, result validation, integration tests for experiment pipelines, and regression baselines
 topics: [research, testing, determinism, validation, integration-tests, regression, tdd]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://the-turing-way.netlify.app/reproducible-research/testing.html
 ---
 
 Research code is notoriously undertested because "the results are stochastic" feels like an excuse. It is not. The experiment runner, evaluation framework, data pipeline, and state management are all deterministic and must be tested rigorously. The stochastic parts (experiment outcomes) require seed-based determinism tests and statistical validation. Untested experiment loops produce unreliable results that waste compute and mislead researchers.

package/content/knowledge/review/review-adr.md

@@ -2,6 +2,12 @@
 name: review-adr
 description: Failure modes and review passes specific to Architecture Decision Records
 topics: [adr, decisions, review]
+volatility: stable
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://adr.github.io/
+  - url: https://github.com/joelparkerhenderson/architecture-decision-record
 ---
 
 # Review: Architecture Decision Records

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

@@ -2,6 +2,12 @@
 name: review-api-design
 description: Failure modes and review passes specific to API contract specifications
 topics: [api, contracts, rest, graphql, review]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://spec.openapis.org/
+  - url: https://spec.graphql.org/
 ---
 
 # Review: API Contracts

package/content/knowledge/review/review-art-bible.md

@@ -2,6 +2,10 @@
 name: review-art-bible
 description: Failure modes and review passes specific to Art Bible documents — budget consistency, naming conventions, LOD coverage, and pipeline validation
 topics: [game-dev, review, art, assets, lod, naming]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources: []
 ---
 
 # Review: Art Bible

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

@@ -2,6 +2,11 @@
 name: review-database-design
 description: Failure modes and review passes specific to database schema design artifacts
 topics: [database, schema, data-modeling, review]
+volatility: evolving
+last-reviewed: null
+version-pin: null
+sources:
+  - url: https://www.postgresql.org/docs/
 ---
 
 # Review: Database Schema