@vue-skuilder/db 0.1.22 → 0.1.24

package/dist/{types-DQaXnuoc.d.ts → types-CJrLM1Ew.d.ts}

@@ -1,5 +1,5 @@
 import { CourseConfig } from '@vue-skuilder/common';
-import { D as DocType } from './types-legacy-DDY4N-Uq.js';
+import { D as DocType } from './types-legacy-JXDxinpU.js';
 
 interface StaticCourseManifest {
     version: string;

package/dist/{types-Bn0itutr.d.cts → types-W8n-B6HG.d.cts}

@@ -1,5 +1,5 @@
 import { CourseConfig } from '@vue-skuilder/common';
-import { D as DocType } from './types-legacy-DDY4N-Uq.cjs';
+import { D as DocType } from './types-legacy-JXDxinpU.cjs';
 
 interface StaticCourseManifest {
     version: string;

package/dist/{types-legacy-DDY4N-Uq.d.cts → types-legacy-JXDxinpU.d.cts}

@@ -14,7 +14,9 @@ declare enum DocType {
     SCHEDULED_CARD = "SCHEDULED_CARD",
     TAG = "TAG",
     NAVIGATION_STRATEGY = "NAVIGATION_STRATEGY",
-    STRATEGY_STATE = "STRATEGY_STATE"
+    STRATEGY_STATE = "STRATEGY_STATE",
+    USER_OUTCOME = "USER_OUTCOME",
+    STRATEGY_LEARNING_STATE = "STRATEGY_LEARNING_STATE"
 }
 interface QualifiedCardID {
     courseID: string;
@@ -91,6 +93,8 @@ declare const DocTypePrefixes: {
     readonly PEDAGOGY: "PEDAGOGY";
     readonly NAVIGATION_STRATEGY: "NAVIGATION_STRATEGY";
     readonly STRATEGY_STATE: "STRATEGY_STATE";
+    readonly USER_OUTCOME: "USER_OUTCOME";
+    readonly STRATEGY_LEARNING_STATE: "STRATEGY_LEARNING_STATE";
 };
 interface CardHistory<T extends CardRecord> {
     _id: PouchDB.Core.DocumentId;

package/dist/{types-legacy-DDY4N-Uq.d.ts → types-legacy-JXDxinpU.d.ts}

@@ -14,7 +14,9 @@ declare enum DocType {
     SCHEDULED_CARD = "SCHEDULED_CARD",
     TAG = "TAG",
     NAVIGATION_STRATEGY = "NAVIGATION_STRATEGY",
-    STRATEGY_STATE = "STRATEGY_STATE"
+    STRATEGY_STATE = "STRATEGY_STATE",
+    USER_OUTCOME = "USER_OUTCOME",
+    STRATEGY_LEARNING_STATE = "STRATEGY_LEARNING_STATE"
 }
 interface QualifiedCardID {
     courseID: string;
@@ -91,6 +93,8 @@ declare const DocTypePrefixes: {
     readonly PEDAGOGY: "PEDAGOGY";
     readonly NAVIGATION_STRATEGY: "NAVIGATION_STRATEGY";
     readonly STRATEGY_STATE: "STRATEGY_STATE";
+    readonly USER_OUTCOME: "USER_OUTCOME";
+    readonly STRATEGY_LEARNING_STATE: "STRATEGY_LEARNING_STATE";
 };
 interface CardHistory<T extends CardRecord> {
     _id: PouchDB.Core.DocumentId;

package/dist/util/packer/index.d.cts

@@ -1,5 +1,5 @@
-export { A as AttachmentData, C as ChunkMetadata, D as DesignDocument, I as IndexMetadata, a as PackedCourseData, P as PackerConfig, S as StaticCourseManifest } from '../../types-Bn0itutr.cjs';
-export { C as CouchDBToStaticPacker } from '../../index-B_j6u5E4.cjs';
+export { A as AttachmentData, C as ChunkMetadata, D as DesignDocument, I as IndexMetadata, a as PackedCourseData, P as PackerConfig, S as StaticCourseManifest } from '../../types-W8n-B6HG.cjs';
+export { C as CouchDBToStaticPacker } from '../../index-Ba7hYbHj.cjs';
 import '@vue-skuilder/common';
-import '../../types-legacy-DDY4N-Uq.cjs';
+import '../../types-legacy-JXDxinpU.cjs';
 import 'moment';

package/dist/util/packer/index.d.ts

@@ -1,5 +1,5 @@
-export { A as AttachmentData, C as ChunkMetadata, D as DesignDocument, I as IndexMetadata, a as PackedCourseData, P as PackerConfig, S as StaticCourseManifest } from '../../types-DQaXnuoc.js';
-export { C as CouchDBToStaticPacker } from '../../index-Dj0SEgk3.js';
+export { A as AttachmentData, C as ChunkMetadata, D as DesignDocument, I as IndexMetadata, a as PackedCourseData, P as PackerConfig, S as StaticCourseManifest } from '../../types-CJrLM1Ew.js';
+export { C as CouchDBToStaticPacker } from '../../index-BWvO-_rJ.js';
 import '@vue-skuilder/common';
-import '../../types-legacy-DDY4N-Uq.js';
+import '../../types-legacy-JXDxinpU.js';
 import 'moment';

package/docs/brainstorm-navigation-paradigm.md

@@ -1,6 +1,10 @@
 # Brainstorm: Navigation Paradigm Exploration
 
 > **Status:** Informal brainstorming. Not a design doc or TODO.
+>
+> **Note:** Many concepts explored here have since been implemented.
+> See `navigators-architecture.md` for current architecture and
+> `devlog/1032-orchestrator` for evolutionary orchestration implementation.
 
 This document explores the navigation strategy paradigm: what other strategy types
 might exist, where the current design shines or struggles, and what alternative
@@ -79,7 +83,8 @@ Trigger-response generators need:
 4. **Exit criteria** — When does intervention end?
 
 This argues for strategies having **lifecycle state**, not just stateless scoring.
-See `todo-strategy-state-storage.md` for related concerns.
+**Update:** Strategy state storage is now implemented via `StrategyStateDoc` — see
+`navigators-architecture.md` for details.
 
 ---
 
@@ -138,7 +143,7 @@ Strategies are instantiated per-request. No persistence of:
 - "Last time I surfaced tag X was..."
 - "This user responds well to strategy Y"
 
-**Mitigation:** `todo-strategy-state-storage.md` (not implemented)
+**Mitigation:** ✅ Implemented via `StrategyStateDoc` — see `navigators-architecture.md`
 
 ### 2. Pull-Only Model
 
@@ -255,25 +260,30 @@ rules:
 **Pros:** Declarative, inspectable, author-configurable
 **Cons:** Limited expressiveness, new DSL to maintain
 
-### 4. Bandit Selection (Planned)
+### 4. Bandit-Style Selection (IMPLEMENTED ✅)
 
-Instead of a fixed pipeline, select among N candidate pipelines:
+Strategies carry **learnable weights** that automatically tune based on outcomes:
 
 ```
-PipelineA: ELO
-PipelineB: Hierarchy(ELO)
-PipelineC: Interference(Hierarchy(ELO))
-
-Orchestrator selects pipeline per-session based on:
-- User cohort
-- Historical effectiveness
-- Exploration/exploitation balance
+Strategy weights = { weight: 1.2, confidence: 0.8, sampleSize: 500 }
+
+Users are distributed across weight space via deviation:
+  effectiveWeight = peakWeight + deviation * spread
+  
+Gradient learning correlates deviation with outcomes:
+  +deviation → +outcome → increase peak
+  +deviation → -outcome → decrease peak
 ```
 
-**Pros:** Learns what works, self-improving
-**Cons:** Requires outcome measurement, cold-start problem
+**Implemented features:**
+- LearnableWeight on strategies
+- Deviation-based cohort distribution
+- Outcome recording per user/period
+- Gradient computation via linear regression
+- Automatic weight updates
+- Observability API endpoints
 
-See `todo-evolutionary-orchestration.md`.
+See `navigators-architecture.md` for details.
 
 ### 5. LLM-Guided Selection
 
@@ -316,23 +326,20 @@ Solver finds valid card sequence.
 
 Rather than wholesale paradigm shift, extend current model:
 
-### Near-term (compatible with naive orchestration)
+### Completed ✅
 
-1. **Richer context** — Pass session state to strategies
-2. **Trigger-response generator** — New generator type with activation state
-3. **Session-scoped state** — Allow strategies to persist within-session
+1. **Pipeline architecture** — Generators + Filters with provenance tracking
+2. **Strategy state storage** — User-scoped persistence via `StrategyStateDoc`
+3. **Evolutionary orchestration** — Learnable weights with gradient learning
+4. **Outcome measurement** — `UserOutcomeRecord` for tracking effectiveness
+5. **Observability** — API endpoints and admin dashboard
 
-### Medium-term (with strategy state storage)
+### Still Applicable
 
-4. **Cross-session state** — Strategies remember past sessions
-5. **Event hooks** — Strategies can subscribe to card results
-6. **Intervention protocol** — Active intervention preempts normal generation
-
-### Long-term (with evolutionary orchestration)
-
-7. **Bandit selection** among pipelines
-8. **Outcome measurement** for strategy effectiveness
-9. **Hybrid architectures** where blackboard/reactive patterns augment pipeline
+1. **Trigger-response generators** — Event-driven strategies with activation state
+2. **Richer context** — Session state, temporal context
+3. **Event hooks** — Strategies subscribing to card results
+4. **Intervention protocol** — Active intervention preempts normal generation
 
 ---
 
@@ -362,8 +369,7 @@ Rather than wholesale paradigm shift, extend current model:
 
 ## Related Documents
 
-- `navigators-architecture.md` — Current architecture
-- `todo-naive-orchestration.md` — Pipeline assembly (prerequisite)
-- `todo-strategy-state-storage.md` — State persistence
-- `todo-evolutionary-orchestration.md` — Bandit selection vision
-- `todo-provenance.md` — Audit trail (transparency)
+- `navigators-architecture.md` — Current architecture (includes evolutionary orchestration)
+- `future-orchestration-vision.md` — Remaining vision items (programmable strategies, self-healing)
+- `todo-strategy-authoring.md` — Strategy creation tools (UI complete)
+- `devlog/1032-orchestrator` — Evolutionary orchestration implementation

package/docs/future-orchestration-vision.md

@@ -0,0 +1,216 @@
+# Future Orchestration Vision
+
+This document tracks aspirational features for the evolutionary orchestration system
+that extend beyond the current implementation.
+
+## Status: VISION / NOT STARTED
+
+> **Prerequisite:** The core orchestration system (learnable weights, deviation-based
+> distribution, gradient learning) is implemented. See `navigators-architecture.md`
+> for the current architecture.
+
+---
+
+## Implemented (Reference)
+
+The following are **complete** and documented in `navigators-architecture.md`:
+
+- ✅ LearnableWeight interface with weight, confidence, sampleSize
+- ✅ Deviation-based weight distribution (bell curve sampling)
+- ✅ UserOutcomeRecord for tracking learning outcomes
+- ✅ Gradient computation via linear regression
+- ✅ Automatic weight updates based on gradient
+- ✅ Observability API endpoints (6 endpoints)
+- ✅ Admin dashboard in platform-ui
+
+---
+
+## Remaining Vision
+
+### 1. Parameterizable / Programmable Strategies
+
+**Goal:** Enable template-based prerequisite rules that generalize across courses.
+
+```typescript
+interface ParameterizedPrerequisite {
+  pattern: "grade-{n} & {subject}";
+  implies: "grade-{n+1} & {subject}";
+  constraints: {
+    n: { type: "number", min: 1, max: 12 },
+    subject: { type: "tag-category", category: "academic-subject" }
+  };
+}
+```
+
+**Example use cases:**
+- `grade-3 & geometry` → requires `grade-2 & geometry`
+- `unit-{n} & {topic}` → requires `unit-{n-1} & {topic}`
+- Cross-course strategy reuse without copy-paste
+
+**What's needed:**
+1. Template syntax design
+2. Variable binding and substitution
+3. Rule engine to evaluate parameterized rules
+4. Cross-course strategy registry
+
+---
+
+### 2. Self-Healing Content
+
+**Goal:** Automatically identify learning barriers and surface them to authors.
+
+**Barrier signals:**
+- High failure rate on specific cards/tags
+- ELO stagnation on specific topics
+- Long dwell time before mastery
+- Drop-off (users abandon at specific points)
+- Cohort-wide plateau detection
+
+**Components needed:**
+1. **Barrier Detection Pipeline** — Analyze outcomes to identify stuck points
+2. **Alert System** — Notify authors of identified barriers
+3. **Intervention Hooks** — Enable targeted content insertion
+4. **Feedback Loop** — Measure whether interventions resolve barriers
+
+**Example flow:**
+```
+Detection: 40% of users fail on "long-division-with-remainders" after
+           mastering "long-division-no-remainder"
+
+Alert: "Learning barrier detected between division topics.
+        Consider intermediate content for remainder concept."
+
+Author action: Adds 5 cards on "remainder as leftover" concept
+
+Feedback: Barrier detection re-runs, measures improvement
+```
+
+---
+
+### 3. Cross-Course Strategy Sharing
+
+**Goal:** Strategies that prove effective in one course can be shared and
+adapted to other courses.
+
+**Components:**
+- Strategy export/import format
+- Cross-course strategy registry
+- Adaptation hints for tag mapping
+- Reputation/effectiveness scores from source course
+
+---
+
+### 4. Author Incentive Mechanisms
+
+**Goal:** Create feedback loops that reward authors for effective content.
+
+**Potential signals:**
+- User outcomes correlated with specific content
+- Content utility weights (cards that consistently help)
+- Barrier resolution credit
+
+**Considerations:**
+- How to attribute outcomes to specific content when many cards contribute?
+- How to handle content that is effective but not "fun"?
+- Privacy implications of tracking detailed content effectiveness
+
+---
+
+### 5. Trigger-Response Generators
+
+**Goal:** Event-driven generators that activate under specific conditions.
+
+```typescript
+interface TriggerResponseGenerator {
+  trigger: {
+    condition: 'failureSpike' | 'plateau' | 'returnAfterGap' | 'frustration';
+    parameters: Record<string, number>;
+  };
+  response: {
+    mode: 'remedial' | 'confidence-building' | 'capstone';
+    targetTags?: string[];
+    duration?: { cards?: number; minutes?: number };
+  };
+}
+```
+
+**Example triggers:**
+- Frustration signal (N failures in M minutes) → easier content
+- Plateau detection (no ELO movement for K sessions) → challenging content
+- Inactivity return (first session after gap) → review-heavy session
+
+**What's needed:**
+- Event bus / signal mechanism for strategies to observe events
+- Activation state tracking ("I am currently intervening on tag T")
+- Priority over base generator (preempt vs blend)
+- Exit criteria (when does intervention end)
+
+See `brainstorm-navigation-paradigm.md` for detailed exploration.
+
+---
+
+### 6. Cohort-Aware Calibration
+
+**Goal:** Use population data to improve cold-start behavior.
+
+**Applications:**
+- Initial card difficulty estimates from population performance
+- Initial interval estimates based on similar users
+- Strategy weight priors from population effectiveness
+
+---
+
+### 7. LLM-Guided Selection (Experimental)
+
+**Goal:** Use language models to interpret learner state and select content.
+
+```
+Given:
+- User profile: { elo: 950, strugglingWith: ['vowel-sounds'], ... }
+- Session context: { duration: 12min, cardsSeen: 8, recentFailures: 2 }
+- Available cards: [...]
+
+Select the next 5 cards and explain reasoning.
+```
+
+**Considerations:**
+- Latency and cost
+- Unpredictability and debugging difficulty
+- When is LLM guidance worth the overhead?
+
+---
+
+## Design Decisions Ahead
+
+### Centralized vs Decentralized Orchestration
+
+**Option A: Central Orchestrator Service**
+- Single service decides strategy application
+- Cleaner cohort tracking
+- Requires backend infrastructure
+
+**Option B: Client-Side Orchestration**
+- Each client computes its own strategy set
+- Works offline
+- Harder to track cohorts
+
+**Current:** Hybrid — client computes from synced registry, outcomes reported to backend.
+
+### Outcome Attribution
+
+When multiple strategies are active, how do we attribute outcomes?
+
+- All strategies get credit/blame equally?
+- Weight by score contribution?
+- Require isolated A/B cells?
+
+**Current:** Equal attribution. Future work may instrument isolated testing.
+
+---
+
+## Related Documents
+
+- `navigators-architecture.md` — Current implementation (complete)
+- `brainstorm-navigation-paradigm.md` — Exploration of alternative mechanisms
+- `todo-strategy-authoring.md` — Strategy creation tools
+- `devlog/1032-orchestrator` — Implementation details

package/docs/navigators-architecture.md

@@ -5,6 +5,9 @@
 The navigation strategy system selects and scores cards for study sessions. It uses a
 **Pipeline architecture** where generators produce candidates and filters transform scores.
 
+An **Evolutionary Orchestration** layer enables strategies to carry learnable weights that
+automatically tune toward optimal values based on observed learning outcomes.
+
 ## Core Concepts
 
 ### WeightedCard
@@ -27,6 +30,7 @@ interface StrategyContribution {
   action: 'generated' | 'passed' | 'boosted' | 'penalized';
   score: number;              // Score after this strategy
   reason: string;             // Human-readable explanation
+  deviation?: number;         // User's deviation from peak weight (evolutionary)
 }
 ```
 
@@ -82,7 +86,7 @@ class Pipeline {
   )
 
   async getWeightedCards(limit: number): Promise<WeightedCard[]> {
-    // Build shared context (user ELO, etc.)
+    // Build shared context (user ELO, orchestration context, etc.)
     const context = await this.buildContext();
 
     // Generate candidates
@@ -104,7 +108,7 @@ class Pipeline {
 ```
 
 **Responsibilities:**
-- **Context building** — Fetches shared data (user ELO) once for all strategies
+- **Context building** — Fetches shared data (user ELO, orchestration context) once for all strategies
 - **Data hydration** — Pre-fetches commonly needed data (tags) in batch queries
 - **Filter orchestration** — Applies filters in sequence, accumulating provenance
 - **Result selection** — Removes zero-scores, sorts, and returns top N
@@ -170,7 +174,8 @@ provenance: [
     strategyId: 'NAVIGATION_STRATEGY-hierarchy-phonics',
     action: 'passed',
     score: 0.85,
-    reason: 'Prerequisites met, tags: letter-sounds'
+    reason: 'Prerequisites met, tags: letter-sounds',
+    deviation: 0.23  // User's position on bell curve for this strategy
   },
   {
     strategy: 'eloDistance',
@@ -185,6 +190,171 @@ provenance: [
 
 Use `getCardOrigin(card)` to extract 'new', 'review', or 'failed' from provenance.
 
+---
+
+## Evolutionary Orchestration
+
+The orchestration layer enables strategies to **learn optimal weights** from observed
+learning outcomes. Instead of fixed configuration, strategies carry **learnable weights**
+that automatically tune toward effectiveness.
+
+### LearnableWeight
+
+Every strategy can carry a learnable weight:
+
+```typescript
+interface LearnableWeight {
+  weight: number;       // Peak value, 1.0 = neutral, range [0.1, 3.0]
+  confidence: number;   // 0-1, controls exploration width
+  sampleSize: number;   // Total observations for this strategy
+
+  history?: Array<{     // Optional: for visualization
+    timestamp: string;
+    weight: number;
+    confidence: number;
+    gradient: number;
+  }>;
+}
+```
+
+Strategies extend with:
+
+```typescript
+interface ContentNavigationStrategyData {
+  // ... existing fields ...
+  learnable?: LearnableWeight;   // Omitted = default weight 1.0
+  staticWeight?: boolean;        // If true, not subject to learning
+}
+```
+
+### Deviation-Based Weight Distribution
+
+Each user experiences a **stable deviation** from the peak weight:
+
+```
+effectiveWeight(user, strategy) = peakWeight + deviation * spread
+
+where:
+  deviation = hash(userId, strategyId, salt) → [-1, 1]  // stable per user
+  spread = max(MIN_SPREAD, (1 - confidence) * MAX_SPREAD)
+```
+
+**Key insight:** Deviation is constant for a user. As confidence grows and spread
+shrinks, all users are pulled toward the optimal peak.
+
+```typescript
+// Example: Low confidence = wide exploration
+{ weight: 1.0, confidence: 0.2 }
+→ spread = 0.8 * MAX_SPREAD
+→ users range from weight 0.6 to 1.4
+
+// Example: High confidence = narrow convergence
+{ weight: 1.2, confidence: 0.9 }
+→ spread = 0.1 * MAX_SPREAD
+→ users cluster around weight 1.15 to 1.25
+```
+
+### Outcome Recording
+
+At the end of each learning period, user outcomes are recorded:
+
+```typescript
+interface UserOutcomeRecord {
+  _id: `USER_OUTCOME::${courseId}::${periodId}`;
+  docType: DocType.USER_OUTCOME;
+  userId: string;
+  courseId: string;
+  periodStart: string;
+  periodEnd: string;
+  strategyExposures: Array<{
+    strategyId: string;
+    deviation: number;      // User's stable deviation for this strategy
+  }>;
+  outcomeValue: number;     // 0-1 learning outcome signal
+}
+```
+
+The outcome signal combines multiple factors:
+- Accuracy within target zone (not too easy, not too hard)
+- ELO progression
+- Session completion
+
+### Gradient Learning
+
+The system discovers optimal weights by correlating **deviation with outcomes**
+across users:
+
+```
++deviation → +outcome = positive gradient → increase peak weight
++deviation → -outcome = negative gradient → decrease peak weight
+flat gradient = at optimum, increase confidence
+```
+
+Linear regression on (deviation, outcome) pairs produces:
+- **Gradient**: Direction to adjust peak
+- **R²**: Signal quality (high = consistent effect)
+- **Sample size**: Update confidence
+
+### Weight Update Cycle
+
+Periodically (or on-demand), the system updates strategy weights:
+
+```typescript
+async function runPeriodUpdate(courseId: string): Promise<void> {
+  for (const strategy of await getLearnableStrategies(courseId)) {
+    const observations = await aggregateOutcomesForGradient(strategy);
+    const { gradient, rSquared } = computeStrategyGradient(observations);
+    await updateStrategyWeight(strategy, gradient, rSquared);
+  }
+}
+```
+
+**Update rules:**
+- Positive gradient → increase peak weight
+- Negative gradient → decrease peak weight
+- Consistent observations → increase confidence
+- Noisy observations → decrease confidence
+
+### Observability
+
+The orchestration layer exposes API endpoints for monitoring:
+
+| Endpoint | Purpose |
+|----------|---------|
+| `GET /orchestration/:courseId/state` | All learning states |
+| `GET /orchestration/:courseId/weights` | Current weights summary |
+| `GET /orchestration/:courseId/strategy/:id/history` | Weight trajectory over time |
+| `GET /orchestration/:courseId/strategy/:id/scatter` | Deviation vs outcome data |
+| `GET /orchestration/:courseId/strategy/:id/distribution` | Bell curve visualization |
+| `POST /orchestration/:courseId/update` | Trigger period update |
+
+An admin dashboard in platform-ui visualizes strategy weights, confidence,
+gradient direction, and historical trajectories.
+
+### Lifecycle
+
+```
+New strategy:    Low confidence → wide spread → noisy gradient → big adjustments
+Learning:        Gradient visible → peak drifts → confidence grows → spread shrinks
+Converged:       High confidence → minimum spread → flat gradient → stable
+Disturbed:       Gradient reappears → peak drifts → adapts to new optimal
+```
+
+### Static vs Learnable
+
+Set `staticWeight: true` for foundational strategies that should not be tuned:
+
+```typescript
+{
+  strategyType: 'hierarchyDefinition',
+  name: 'Core Prerequisites',
+  staticWeight: true,  // Never tuned by orchestration
+  // learnable field ignored
+}
+```
+
+---
+
 ## Creating New Strategies
 
 ### Generator
@@ -249,6 +419,8 @@ class MyFilter extends ContentNavigator implements CardFilter {
 
 Register in `NavigatorRoles` as `NavigatorRole.FILTER`.
 
+---
+
 ## Strategy State Storage
 
 Strategies can persist user-scoped state (preferences, learned patterns, temporal tracking)
@@ -294,7 +466,7 @@ interface StrategyStateDoc<T> {
   courseId: string;
   strategyKey: string;
   data: T;               // Strategy-specific payload
-  updatedAt: string;     // ISO timestamp
+  updatedAt: string;
 }
 ```
 
@@ -332,6 +504,8 @@ return { ...card, score: card.score * multiplier };
 - All sliders share global max for consistent visual comparison
 - Writes to strategy state via `userDB.putStrategyState()`
 
+---
+
 ## File Reference
 
 | File | Purpose |
@@ -355,9 +529,18 @@ return { ...card, score: card.score * multiplier };
 | `core/navigators/inferredPreference.ts` | Inferred preference navigator (stub) |
 | `core/types/strategyState.ts` | `StrategyStateDoc`, `StrategyStateId` |
 | `impl/couch/courseDB.ts` | `createNavigator()` entry point |
+| `core/orchestration/index.ts` | OrchestrationContext, deviation logic |
+| `core/orchestration/gradient.ts` | Gradient computation |
+| `core/orchestration/learning.ts` | Weight updates, period orchestration |
+| `core/orchestration/signal.ts` | Outcome signal computation |
+| `core/orchestration/recording.ts` | User outcome recording |
+| `core/types/learningState.ts` | `StrategyLearningState` |
+| `core/types/userOutcome.ts` | `UserOutcomeRecord` |
+| `express/routes/orchestration.ts` | Observability API endpoints |
 
 ## Related Documentation
 
 - `todo-strategy-authoring.md` — UX and DX for authoring strategies
-- `todo-evolutionary-orchestration.md` — Long-term adaptive strategy vision
+- `future-orchestration-vision.md` — Long-term adaptive strategy vision (beyond current implementation)
 - `devlog/1004` — Implementation details for tag hydration optimization
+- `devlog/1032-orchestrator` — Evolutionary orchestration implementation details