save checkpoint: save features

docs/modules/binary-index/architecture.md

@@ -31,6 +31,11 @@ BinaryIndex provides three tiers of binary identification:
 | B | Build-ID/hash catalog (exact binary identity) | High | Medium |
 | C | Function fingerprints (CFG/basic-block hashes) | Very High | Targeted |
 
+Tier B catalog lookups are performed over three identity dimensions:
+- `BuildId + BuildIdType`
+- `BinaryKey`
+- `FileSha256`
+
 ### 1.3 Module Scope
 
 **In Scope:**
@@ -136,6 +141,9 @@ public interface IBinaryCorpusConnector
 - `DebianBinaryCorpusConnector` - Debian/Ubuntu packages + debuginfo
 - `RpmBinaryCorpusConnector` - RHEL/Fedora/CentOS + SRPM
 - `AlpineBinaryCorpusConnector` - Alpine APK + APKBUILD
+- `DebianMirrorPackageSource` - Debian package index/payload mirror source
+- `AlpineMirrorPackageSource` - Alpine package index/payload mirror source with cache fallback
+- `RpmMirrorPackageSource` - RPM primary metadata/package mirror source with cache fallback
 
 #### 2.2.2 Binary Feature Extractor
 
@@ -389,6 +397,11 @@ public decimal SemanticWeight { get; init; } = 0.2m;
 public SemanticFingerprint? SemanticFingerprint { get; init; }
 ```
 
+**Patch Diff Result Storage Contract:**
+- `IDiffResultStore` persists `PatchDiffResult` records with deterministic, content-addressed IDs in the in-memory implementation.
+- Re-storing an identical result yields the same ID (idempotent storage), while content changes produce a different ID.
+- Rename detection and result-store persistence behaviors are covered by `StellaOps.BinaryIndex.Diff.Tests` unit suites.
+
 ##### 2.2.5.5 Test Coverage
 
 | Category | Tests | Coverage |
@@ -527,6 +540,13 @@ BinaryIndex exposes operational endpoints for health, benchmarking, cache monito
 | `/api/v1/ops/binaryindex/cache` | GET | Function IR cache hit/miss statistics |
 | `/api/v1/ops/binaryindex/config` | GET | Effective configuration (secrets redacted) |
 
+For local/offline startup, `StellaOps.BinaryIndex.WebService` registers
+`InMemoryBinaryVulnerabilityService` as a deterministic fallback for
+`IBinaryVulnerabilityService` when persistence-backed providers are not wired.
+It also composes `InMemoryDeltaSignatureRepository` as a deterministic fallback
+for `IDeltaSignatureRepository` so `PatchCoverageController` endpoints remain
+callable when PostgreSQL-backed signature repositories are unavailable.
+
 **Health Response:**
 ```json
 {
@@ -956,6 +976,12 @@ BinaryIndex exposes read-only ops endpoints for health, bench, cache, and effect
 | `/api/v1/ops/binaryindex/cache` | GET | `BinaryIndexFunctionCacheStats` | Function cache hit/miss/eviction statistics |
 | `/api/v1/ops/binaryindex/config` | GET | `BinaryIndexEffectiveConfig` | Effective configuration with secrets redacted |
 
+Startup safety: the WebService composes a deterministic fallback
+`IBinaryVulnerabilityService` implementation to keep API host boot valid in
+local/offline environments where persistence dependencies are intentionally absent.
+The same startup safety contract applies to patch-coverage API routes through
+a deterministic `IDeltaSignatureRepository` fallback implementation.
+
 #### 7.3.1 Response Schemas
 
 **BinaryIndexOpsHealthResponse:**
@@ -1740,4 +1766,4 @@ inside `AddNormalizationPipelines()` in `ServiceCollectionExtensions.cs`.
 ---
 
 *Document Version: 1.5.0*
-*Last Updated: 2026-02-08*
+*Last Updated: 2026-02-12*

docs/modules/doctor/architecture.md

@@ -14,6 +14,41 @@ Doctor provides a plugin-based diagnostic system that enables:
 - **Capability probing** for feature compatibility
 - **Evidence collection** for troubleshooting and compliance
 
+### Scheduler Runtime Surface (run-002 remediation)
+
+Doctor Scheduler now exposes an HTTP management and trend surface at:
+- `GET/POST /api/v1/doctor/scheduler/schedules`
+- `GET/PUT/DELETE /api/v1/doctor/scheduler/schedules/{scheduleId}`
+- `GET /api/v1/doctor/scheduler/schedules/{scheduleId}/executions`
+- `POST /api/v1/doctor/scheduler/schedules/{scheduleId}/execute`
+- `GET /api/v1/doctor/scheduler/trends`
+- `GET /api/v1/doctor/scheduler/trends/checks/{checkId}`
+- `GET /api/v1/doctor/scheduler/trends/categories/{category}`
+- `GET /api/v1/doctor/scheduler/trends/degrading`
+
+The default local runtime uses deterministic in-memory repositories with stable ordering for schedule lists, execution history, and trend summaries.
+
+### AdvisoryAI Diagnosis Surface (run-003 remediation)
+
+Doctor WebService now exposes a diagnosis endpoint for AdvisoryAI-backed health analysis:
+- `POST /api/v1/doctor/diagnosis`
+
+The endpoint accepts either:
+- `runId` referencing a stored Doctor report, or
+- an inline `DoctorRunResultResponse` payload.
+
+Runtime wiring includes:
+- `IDoctorContextAdapter` for deterministic context projection from Doctor reports
+- `IDoctorAIDiagnosisService` (deterministic implementation) for assessment, root cause, correlation, and remediation projection
+- schema enrichment through `IEvidenceSchemaRegistry.RegisterCommonSchemas()`
+
+### AdvisoryAI Diagnosis Surface (run-002 remediation)
+
+Doctor WebService now exposes an AdvisoryAI diagnosis endpoint:
+- `POST /api/v1/doctor/diagnosis`
+
+The endpoint accepts either inline Doctor run payloads or a persisted `runId`, maps them through the shared Doctor AdvisoryAI context adapter (`src/__Libraries/StellaOps.Doctor/AdvisoryAI/**`), and returns deterministic diagnosis output (issues, root causes, recommended actions, and related runbook links).
+
 ## 2) Plugin Architecture
 
 ### Core Interfaces