freshcontext-mcp 0.3.18 → 0.3.20

package/docs/FUTURE_LANES.md

@@ -0,0 +1,196 @@
+# FreshContext Future Lanes
+
+This document keeps future FreshContext work organized without turning roadmap ideas into public claims.
+
+FreshContext is live today as an integrated MCP/Core package. Future work should stay in lanes, start with audits, and avoid feature sprawl.
+
+The current package boundary is documented in [Core / MCP Boundary](./CORE_MCP_BOUNDARY.md). Treat MCP as the first live host over FreshContext Core, not as the whole product identity.
+
+## Current Live Boundary
+
+Live today:
+
+- npm package: `freshcontext-mcp@0.3.19`
+- MCP stdio server
+- `evaluate_context` MCP tool for caller-provided candidate context
+- Signal Contract v1 as the stable candidate-context input shape
+- 21 read-only reference adapters
+- Core signal evaluation
+- Source Profiles
+- Decision Helper
+- adapter registry metadata
+- arXiv signal-to-decision proof
+- bring-your-own-context local demos
+- Trust Scanner release gate
+
+Not live today:
+
+- Operator / `retrieve(...)`
+- browser crawling
+- automatic local file, folder, or PDF scanning
+- hosted dashboard or billing
+- hard Ha-Pri v2 production enforcement
+- standalone Core SDK package
+- full adapter ingestion
+
+## Phase 0: Stabilize The Signal Contract
+
+Goal:
+
+```text
+Treat Signal Contract v1 as the stable input boundary for FreshContext.
+```
+
+Current contract:
+
+```text
+title + content + source + source_type + published_at + retrieved_at + semantic_score
+```
+
+This is live today. It is not the same thing as future context signals or control signals.
+
+Tasks in this lane should document examples, invalid-input behavior, and normalization expectations. Do not expand required fields unless tests prove the new metadata improves decisions.
+
+Future context signals, control signals, ingestion quality signals, structure preservation signals, and provenance confidence signals belong to later Decision Layer upgrades. They should remain optional metadata, not public required fields.
+
+## Lane 1: Client Setup Reliability
+
+Goal:
+
+```text
+Make Claude, Codex, and MCP-compatible clients connect reliably to the published package.
+```
+
+Start with setup guide audits, Claude Desktop local/global package paths, Codex local MCP config paths, stale global package fixes, and smoke command expectations.
+
+Do not claim ChatGPT/OpenAI connector compatibility until a separate compatibility audit is done.
+
+## Lane 2: Generic Context Evaluation
+
+Goal:
+
+```text
+Let any caller provide candidate context and get decision-ready output.
+```
+
+Current live MCP path:
+
+```text
+evaluate_context
+```
+
+Hard boundary:
+
+```text
+No fetching, crawling, browsing, folder reading, or retrieval orchestration.
+Only evaluate caller-provided candidate context.
+```
+
+Next work in this lane should focus on CLI, SDK, and REST ergonomics over the same caller-provided signal shape.
+
+## Lane 3: Multi-Agent Context Handoff Proof
+
+Goal:
+
+```text
+Show FreshContext as an independent context judgment layer between agents.
+```
+
+Proof shape:
+
+```text
+agent A produces candidate context
+-> FreshContext evaluates it
+-> agent B receives decision-ready context
+```
+
+Do not build a full multi-agent framework. Prove the handoff boundary.
+
+## Lane 4: Core SDK Extraction Audit
+
+Goal:
+
+```text
+Decide whether Core should become a standalone package.
+```
+
+Audit current Core exports, dependency boundaries, package shape, browser/node compatibility, public API stability, and what remains MCP-only.
+
+No extraction without a compatibility plan. Keep `freshcontext-mcp` stable until a standalone Core package has compatibility tests and a migration path.
+
+## Lane 5: Local/User Data Intake Audit
+
+Goal:
+
+```text
+Explore student, research, and local-PC workflows safely.
+```
+
+Candidate sources include notes, PDFs, local JSON/CSV, citation exports, and database rows.
+
+Hard boundary:
+
+```text
+Consent-first design. No automatic folder scanning or background file reading.
+```
+
+## Lane 6: Decision Layer Upgrade
+
+Goal:
+
+```text
+Make decisions more useful without silently changing ranking.
+```
+
+Possible inputs include context utility, control signal, future context signal, ingestion quality, structure preservation, provenance confidence, confidence tiers, and source-profile-specific thresholds.
+
+These are optional future metadata upgrades on top of Signal Contract v1. They should only be exposed when they make decisions clearer without making the caller-facing contract harder to use.
+
+Do not make `utility.score` affect ranking by default without a dedicated ranking policy pass.
+
+## Lane 7: Ha-Pri v2 Production Path
+
+Goal:
+
+```text
+Turn Ha-Pri v2 from pure Core helper/design into production enforcement where appropriate.
+```
+
+Audit canonical content material, storage path, verification timing, failure mode, D1/Worker compatibility, and migration plan.
+
+Do not claim hard tamper enforcement until the read/write path exists.
+
+## Lane 8: GDELT GKG / Richer Source Intelligence
+
+Goal:
+
+```text
+Upgrade GDELT intelligence with richer global knowledge graph signals.
+```
+
+Possible fields include tone, Goldstein scale, event codes, actor geography, theme density, and source timeline.
+
+Do not mix this with generic context evaluation or local intake.
+
+## Lane 9: Operator / Retrieve Orchestration
+
+Goal:
+
+```text
+Coordinate retrieval only after the decision layer and adapter boundaries are mature.
+```
+
+Operator may later select adapters, call retrievers, refresh stale sources, and package best context.
+
+Not now. Operator is a later workflow layer over Core and adapters.
+
+## Operating Rule
+
+Every lane starts with:
+
+```text
+audit -> small patch -> validation -> stop
+```
+
+Do not combine lanes because the architecture is tempting.
+

package/docs/HA_PRI_V2_DESIGN.md

@@ -10,7 +10,13 @@ Ha-Pri v2 is an additive provenance-hardening model for FreshContext Store/Ledge
 
 The goal is to keep Ha-Pri v1 readable while designing a stronger future signature that binds a row to canonical content, semantic identity, source metadata, timestamps, and engine version.
 
-Phase 3-B adds pure Core helper functions and deterministic tests for the v2 model. Phase 3-C adds `examples/ha-pri-v2-example.ts`, a deterministic developer fixture showing `calculateHaPriV2` and `verifyHaPriV2` returning valid, invalid, and unknown verification states. Production Store wiring remains future work. This document does not change the D1 schema, change Worker write paths, migrate old rows, add HMAC secrets, or alter production scoring.
+Phase 3-B adds pure Core helper functions and deterministic tests for the v2 model. Phase 3-C adds `examples/ha-pri-v2-example.ts`, a deterministic developer fixture showing `calculateHaPriV2` and `verifyHaPriV2` returning valid, invalid, and unknown verification states. Production Store wiring remains future work. This document does not change the D1 schema, change Worker write paths, migrate old rows, add HMAC secrets, or alter production scoring.
+
+Pass 11-J adds golden test vectors for the pure Core helpers. Ha-Pri v2 golden vectors prove deterministic Core provenance behavior: canonicalization, SHA-256 hashes, signing payload construction, signature generation, and verification status are stable and repeatable. They do not mean Ha-Pri v2 is production-enforced on Worker/D1 reads.
+
+Plain SHA-256 provides deterministic integrity and audit checks. HMAC or private-key signing would be needed later for stronger origin-authentication guarantees.
+
+Pass 11-K adds a design-only production enforcement plan in `docs/HA_PRI_V2_PRODUCTION_ENFORCEMENT_PLAN.md`. That plan covers the future D1/storage, write-path, read/debug verification, compatibility, backfill, threat model, and rollout path. It does not implement Worker/D1 enforcement.
 
 ## Current Ha-Pri v1 Audit
 

package/docs/HA_PRI_V2_PRODUCTION_ENFORCEMENT_PLAN.md

@@ -0,0 +1,414 @@
+# Ha-Pri v2 Production Enforcement Plan
+
+Status: design only
+Phase: Pass 11-K
+Runtime impact: none
+
+Ha-Pri v2 production enforcement is a future rollout path. Current FreshContext releases only include the Core helper and deterministic golden vectors unless a later implementation pass explicitly wires Worker/D1 enforcement.
+
+This plan describes how Ha-Pri v2 could move from pure Core provenance helper to production Store/Worker verification without overclaiming current behavior.
+
+## 1. Current State
+
+Current FreshContext behavior:
+
+- Ha-Pri v1 is the current Worker/feed audit stamp.
+- Ha-Pri v1 is stored as `scrape_results.ha_pri_sig`.
+- Ha-Pri v1 is returned in Worker feed `intelligence_stamps`.
+- Ha-Pri v1 is a provenance stamp and audit reference, not hard row rejection.
+- Ha-Pri v2 exists as a pure Core helper in `src/core/provenance.ts`.
+- Ha-Pri v2 has deterministic golden vectors in `tests/fixtures/ha-pri-v2-golden-vectors.json`.
+- Ha-Pri v2 is not production-enforced on Worker/D1 reads.
+- Ha-Pri v2 does not currently reject rows.
+- Ha-Pri v2 does not currently provide private-key origin authentication.
+
+The current v2 helper provides deterministic canonicalization, SHA-256 hashing, signing payload construction, signature calculation, and verification status:
+
+```txt
+valid
+invalid
+unknown
+```
+
+That is real Core behavior. It is not yet Worker/D1 enforcement.
+
+## 2. Target Future State
+
+Future production enforcement should make stored context rows independently reviewable after write.
+
+Target behavior:
+
+- Worker write path stores Ha-Pri v2 provenance material for new rows.
+- Rows can later be verified as `valid`, `invalid`, or `unknown`.
+- Debug/internal read paths can report verification status.
+- Safe public read paths can expose limited verification status without leaking internals.
+- Invalid rows are not silently treated as trusted.
+- Old rows remain compatible through `unknown` and optional backfill behavior.
+- Strict rejection remains optional and staged, not the first rollout.
+
+The target is not "FreshContext proves truth." The target is "FreshContext can detect whether stored provenance material still matches the stored row material under the documented v2 contract."
+
+## 3. Proposed D1 / Storage Fields
+
+Essential fields:
+
+```txt
+ha_pri_sig_v2 TEXT
+ha_pri_canonical_content_sha256 TEXT
+ha_pri_semantic_fingerprint_sha256 TEXT
+ha_pri_signing_payload_version TEXT
+ha_pri_engine_version TEXT
+```
+
+Recommended operational fields:
+
+```txt
+ha_pri_verification_status TEXT
+ha_pri_verified_at TEXT
+ha_pri_backfill_status TEXT
+```
+
+Likely unnecessary as separate stored fields:
+
+```txt
+ha_pri_adapter
+ha_pri_published_at
+ha_pri_retrieved_at
+```
+
+Reason: adapter, published timestamp, and retrieved/scraped timestamp already exist or should exist as first-class row fields. Duplicating them inside Ha-Pri-specific columns risks drift. The signing payload should read those canonical row fields directly during verification.
+
+Minimum practical schema:
+
+```sql
+ALTER TABLE scrape_results ADD COLUMN ha_pri_sig_v2 TEXT;
+ALTER TABLE scrape_results ADD COLUMN ha_pri_canonical_content_sha256 TEXT;
+ALTER TABLE scrape_results ADD COLUMN ha_pri_semantic_fingerprint_sha256 TEXT;
+ALTER TABLE scrape_results ADD COLUMN ha_pri_signing_payload_version TEXT;
+ALTER TABLE scrape_results ADD COLUMN ha_pri_engine_version TEXT;
+ALTER TABLE scrape_results ADD COLUMN ha_pri_verification_status TEXT;
+ALTER TABLE scrape_results ADD COLUMN ha_pri_verified_at TEXT;
+ALTER TABLE scrape_results ADD COLUMN ha_pri_backfill_status TEXT;
+```
+
+Storage status values should be boring and explicit:
+
+```txt
+valid
+invalid
+unknown
+not_checked
+```
+
+Backfill status values should avoid pretending old rows were originally v2-stamped:
+
+```txt
+none
+backfilled
+unknown_origin
+failed
+```
+
+## 4. Write-Path Design
+
+The future Worker write path should dual-stamp v1 and v2 for new rows.
+
+Recommended write sequence:
+
+1. Adapter returns raw candidate content.
+2. Existing Worker scoring computes current DAR fields and Ha-Pri v1.
+3. Write path prepares Ha-Pri v2 input:
+   - `resultId`: row id that will be stored
+   - `rawContent`: canonical row raw content
+   - `semanticFingerprint`: semantic fingerprint material or stored fingerprint
+   - `adapter`: adapter id
+   - `publishedAt`: normalized source publication timestamp or `null`
+   - `retrievedAt`: normalized scrape/retrieval timestamp
+   - `engineVersion`: FreshContext engine/package version or explicit Worker engine version
+4. If required v2 material is complete, calculate:
+   - canonical content SHA-256
+   - semantic fingerprint SHA-256
+   - signing payload version
+   - Ha-Pri v2 signature
+5. Store v1 fields as today.
+6. Store v2 fields alongside v1 fields.
+7. If material is incomplete, store unknown-compatible metadata and do not pretend the row is valid.
+
+Recommended incomplete-material behavior:
+
+```txt
+ha_pri_sig_v2 = null
+ha_pri_verification_status = "unknown"
+ha_pri_backfill_status = "none"
+```
+
+Canonical content should be produced by the same pure helper behavior used in Core golden vectors. Do not invent a second Worker-only canonicalization contract.
+
+Semantic fingerprint should be produced before signing and should be stable across retries for the same underlying source item. If the fingerprint is missing, v2 signing should fall back to `unknown`, not a fake valid signature.
+
+Engine version should be explicit. The safest initial choice is the package/server version used by the running Worker build.
+
+## 5. Read / Debug Verification Design
+
+Future read verification should be a pure recomputation:
+
+```txt
+verifyHaPriV2(row) -> valid | invalid | unknown
+```
+
+Suggested internal verification input:
+
+```ts
+{
+  resultId: row.id,
+  rawContent: row.raw_content,
+  semanticFingerprint: row.semantic_fingerprint,
+  adapter: row.adapter,
+  publishedAt: row.published_at,
+  retrievedAt: row.scraped_at,
+  engineVersion: row.ha_pri_engine_version
+}
+```
+
+Debug output may include:
+
+```json
+{
+  "ha_pri_v2": {
+    "status": "valid",
+    "checked_at": "2026-06-11T12:00:00.000Z",
+    "payload_version": "FRESHCONTEXT_HA_PRI_V2",
+    "canonical_content_sha256": "sha256...",
+    "semantic_fingerprint_sha256": "sha256..."
+  }
+}
+```
+
+Safe public output should be smaller:
+
+```json
+{
+  "provenance": {
+    "ha_pri_v2_status": "valid"
+  }
+}
+```
+
+Do not expose signing payloads or debug hashes in broad public outputs unless there is a clear user need.
+
+Suggested staged behavior:
+
+- Phase 1: report-only verification in internal/debug output.
+- Phase 2: warning in read/debug path when invalid.
+- Phase 3: optional strict mode for private deployments.
+- Phase 4: possible reject/block policy only after replay data and operational evidence.
+
+Invalid should not become automatic rejection first. A migration bug, canonicalization mismatch, or schema rollout issue could otherwise hide useful rows during rollout.
+
+## 6. Compatibility And Backfill
+
+Old rows must remain readable.
+
+Compatibility rules:
+
+- v1-only rows verify as `unknown` for v2.
+- Rows with missing v2 fields verify as `unknown`.
+- Rows with malformed v2 signatures verify as `invalid`.
+- Rows with present but mismatched v2 signatures verify as `invalid`.
+- Missing `ha_pri_sig_v2` is not the same as tampering.
+- Existing `ha_pri_sig` remains readable for historical continuity.
+
+Backfill rules:
+
+- Backfilled provenance must be marked as `backfilled` or `unknown_origin`.
+- Backfill must not imply the row was v2-stamped at original write time.
+- Backfill should preserve original row timestamps.
+- Backfill should record when verification/backfill happened.
+- Backfill should be reversible or repeatable where practical.
+
+Possible backfill process:
+
+1. Select rows missing `ha_pri_sig_v2`.
+2. Reconstruct v2 input from stored row fields.
+3. If required material is complete, calculate v2 fields.
+4. Store v2 fields with `ha_pri_backfill_status = "backfilled"`.
+5. If required material is incomplete, store `ha_pri_verification_status = "unknown"` and `ha_pri_backfill_status = "unknown_origin"`.
+6. Report counts for backfilled, unknown, invalid, and failed rows.
+
+## 7. Security Boundary
+
+Plain SHA-256 gives deterministic integrity and audit checks.
+
+Plain SHA-256 does not prove private origin authentication. Anyone with all payload fields can recompute a plain SHA-256 signature.
+
+Ha-Pri v2 helps detect:
+
+- accidental row corruption
+- changed content after write
+- changed semantic fingerprint material
+- changed adapter/timestamp/version fields included in the signing payload
+- malformed stored signatures
+
+Ha-Pri v2 does not solve:
+
+- truth certification
+- legal, medical, tax, employment, academic, or investment correctness
+- private origin authentication without a secret or private key
+- compromise of the write path before signing
+- compromise of all row fields plus signature under plain SHA-256
+
+Recommendation:
+
+Do not add HMAC/private signing immediately to the open package. Keep the open package deterministic and stateless.
+
+Consider HMAC or private-key signing later for:
+
+- hosted FreshContext endpoints
+- private production deployments
+- paid/tenant-specific infrastructure
+- environments where the verifier must know the row was stamped by a trusted FreshContext deployment
+
+If HMAC/private signing is added later, it requires:
+
+- secret storage outside the repo
+- key ids
+- key rotation
+- old-key verification policy
+- signer/verifier boundary documentation
+- tests proving secrets are never logged or returned
+
+## 8. Threat Model
+
+Threats considered:
+
+### Accidental row corruption
+
+Ha-Pri v2 helps by recomputing the expected signature and surfacing `invalid`.
+
+### Stale or partial provenance
+
+Ha-Pri v2 helps by returning `unknown` when required material is missing. The system should not pretend such rows are valid.
+
+### Tampered D1 rows
+
+Ha-Pri v2 helps if an attacker changes stored content or bound fields without also updating all matching v2 fields.
+
+Plain SHA-256 does not help if an attacker can rewrite all row fields and recompute the public signature.
+
+### Malformed signatures
+
+Malformed, blank, or nonmatching signatures should produce `invalid` or `unknown` according to current helper behavior. They should not crash reads.
+
+### Recomputed public SHA-256 signatures
+
+Because v2 currently uses plain SHA-256, a party with all fields can recompute a matching signature. HMAC/private signing is the later answer if origin authentication becomes necessary.
+
+### Debug endpoint leakage
+
+Debug routes should remain authenticated. Public outputs should avoid exposing full signing payloads or internal row material unless deliberately needed.
+
+### Secret exposure if HMAC is added later
+
+HMAC/private signing introduces secret-management risk. Secrets must live in deployment configuration, never in docs, fixtures, npm package output, or client-visible responses.
+
+## 9. Tests Needed Before Implementation
+
+Future implementation should add tests before production rollout:
+
+- D1 migration tests if the migration harness supports them.
+- Write-path stamping tests for new rows.
+- Dual-stamp tests proving v1 remains unchanged.
+- Read-path verification tests for `valid`, `invalid`, and `unknown`.
+- Old-row tests proving missing v2 fields are `unknown`, not invalid.
+- Tampered-row tests for changed content, semantic fingerprint, adapter, timestamps, and engine version.
+- Malformed signature tests.
+- Debug output safety tests.
+- Public output minimization tests.
+- Backfill tests with complete and incomplete rows.
+- Worker dry-run validation.
+- HMAC/private signing tests if that later lands.
+
+Do not add fake production-enforcement tests before implementation exists.
+
+## 10. Rollout Phases
+
+### Phase 0: Core helper and golden vectors
+
+Done.
+
+Includes:
+
+- pure Core Ha-Pri v2 helper
+- deterministic golden vectors
+- valid / invalid / unknown verification behavior
+
+### Phase 1: Storage schema design
+
+This document.
+
+No migration yet.
+
+### Phase 2: Write-path dual-stamp v1 + v2
+
+Add D1 columns and write v2 fields for new rows only. Keep v1 intact.
+
+### Phase 3: Report-only read/debug verification
+
+Recompute v2 on read/debug paths and report status. Do not reject rows yet.
+
+### Phase 4: Backfill tooling
+
+Backfill historical rows only with explicit `backfilled` or `unknown_origin` markers.
+
+### Phase 5: Optional strict mode
+
+Private deployments may opt into warnings or blocking for invalid rows after enough evidence.
+
+### Phase 6: Hosted/private HMAC signing
+
+Add origin-authenticated signing only if hosted/private use cases require it.
+
+## 11. Non-Goals
+
+This pass does not implement:
+
+- D1 migration
+- Worker enforcement
+- read-path rejection
+- debug endpoint changes
+- HMAC/private signing
+- backfill script
+- npm publish
+- version bump
+- Cloudflare deploy
+- public security claim upgrade
+- new MCP tools
+- ranking/scoring changes
+- Operator/retrieve behavior
+
+## Release Gates For Future Implementation
+
+Before any implementation pass can claim production enforcement:
+
+- migrations must be reviewed and dry-run
+- new rows must dual-stamp v1 and v2
+- v1 compatibility tests must pass
+- v2 read verification tests must pass
+- old-row `unknown` behavior must be proven
+- tampered-row `invalid` behavior must be proven
+- debug output must avoid leaking secrets or excessive internals
+- Worker dry-run must pass
+- Trust gate must pass with effective fail 0
+- public docs must say exactly what is implemented
+
+## Product Interpretation
+
+Ha-Pri v2 is a provenance hardening lane for stored FreshContext rows. It supports the larger product story only when it stays honest:
+
+```txt
+candidate context in
+decision-ready context out
+optional provenance verification for stored rows
+```
+
+It is not a truth engine and not a substitute for authentication, authorization, or hosted tenant isolation.

package/docs/RELEASE_INTEGRITY.md

@@ -22,6 +22,7 @@ This document describes release hardening practices for future FreshContext pack
   - Confirm fresh consumer `npm audit --omit=dev` is clean.
 - Run a stale-claim scan across public docs and package-facing files.
 - Run a secret scan before sharing archives, diligence folders, or package artifacts.
+- Keep operational demo runbooks, buyer scripts, outreach plans, diligence checklists, and private commercial materials outside the public npm package.
 
 ## Package Exclusion Checks
 
@@ -34,6 +35,7 @@ Confirm release artifacts do not include:
 - Local database snapshots or SQL dumps.
 - Private sale, buyer, target, outreach, or diligence documents.
 - Private data-room folders.
+- Operational demo runbooks intended for buyer calls or internal screen-share rehearsal.
 - Local logs.
 - Old package tarballs.
 

package/docs/RELEASE_NOTES.md

@@ -1,8 +1,25 @@
 # FreshContext Release Notes
 
+## 0.3.19
+
+FreshContext 0.3.19 syncs the public MCP package with the new generic `evaluate_context` interface.
+
+### Context Evaluation Front Door
+
+- Adds `evaluate_context` as the primary MCP tool for caller-provided candidate context.
+- Returns decision-first output for agents and users: decision, meaning, action, warnings, source, freshness, rank score, utility, confidence, and explanation.
+- Keeps the boundary explicit: `evaluate_context` does not fetch, crawl, scrape, browse, read folders, or call adapters.
+- Updates stdio smoke and Trust Scanner claim checks to expect 22 MCP tools: `evaluate_context` plus 21 read-only reference adapters.
+
+### Public Framing
+
+- Reframes the MCP package around FreshContext as context integrity infrastructure, not a 21-tool toolbox.
+- Keeps the 21 adapter tools as read-only reference adapters and proof surfaces.
+- Updates package-facing docs/spec language to point first at `candidate context -> FreshContext Core -> decision-ready context`.
+
 ## 0.3.18
 
-FreshContext 0.3.18 prepares the next npm package release without changing the deployed Worker or publishing automatically.
+FreshContext 0.3.18 made the MCP/Core package easier to install, validate, and explain without changing the deployed Worker runtime.
 
 ### Core and Context Evaluation
 
@@ -32,7 +49,7 @@ FreshContext 0.3.18 prepares the next npm package release without changing the d
 
 ### Boundaries
 
-- No npm publish in this preparation pass.
-- No git tag in this preparation pass.
-- No deployment in this preparation pass.
-- No Worker, REST handler, Core runtime, MCP tool schema, or adapter behavior changes are included in the version bump itself.
+- No Worker deploy is part of the npm package release.
+- No hosted dashboard, billing system, Operator mode, browser crawling, or local file scanning is included.
+- No Worker, REST handler, MCP tool schema, or existing adapter behavior changes are included in the package release itself.
+- Future work is tracked in [`FUTURE_LANES.md`](./FUTURE_LANES.md).