Add `ContextManager.from_config()` — one declarative config file for budgets, policy, scoring, and routing profiles

[dgenio]

Summary

Provide a single documented YAML/JSON config-file entry point for the library API (mirroring the gateway's mcp serve --config, #346): ContextManager.from_config("contextweaver.yaml") constructing budgets, policy, scoring config, profile, and store choices, with JSON-Schema validation and clear errors.

Why this matters

The gateway already proved the value of zero-Python configuration; library users (and platform teams standardizing settings across many agents) still must hand-wire ContextBudget, ContextPolicy, ScoringConfig, and ProfileConfig in code. A canonical config file makes deployments reviewable, diffable, and consistent, and gives the init scaffold a real target.

Current evidence

• contextweaver init scaffolds config + sample catalog (__main__.py), but there is no from_config constructor on ContextManager (grep from_config|load_config in context/manager.py, config.py, profiles.py: no matches).
• _mcp_cli.py implements --config FILE for mcp serve (issue feat: package the MCP context gateway as a zero-Python drop-in proxy (Claude Desktop / Cursor / VS Code) #346) — precedent and parsing conventions exist.
• All config dataclasses already have to_dict/from_dict (closed [config] Add to_dict()/from_dict() to ContextPolicy, ContextBudget, and ScoringConfig #184), so the mapping layer is mostly done.
• _schema_gen.py can generate a config JSON Schema for editor validation (pattern from issue [contracts] Publish JSON Schemas + CI drift check (closes #196) #225).

External context

Declarative config files with published JSON Schemas (editor autocomplete via schemastore-style $schema) are the ecosystem norm for infrastructure libraries.

Proposed implementation

1. Define the file shape (top-level keys: budget, policy, scoring, profile, stores, optional routing); reuse from_dict on each dataclass.
2. Implement ContextManager.from_config(path | dict) in a small new module (context/config_file.py) to respect the ≤300-line rule; validate against a generated schema with jsonschema (already core).
3. Store selection: named built-ins only (memory, sqlite:…, json_dir:…) — no arbitrary import-by-string (avoid code-execution-from-config risk).
4. Generate + commit schemas/manager_config.schema.json via _schema_gen.py and gate with schemas-check.
5. Teach contextweaver init to emit the new file with comments; have build/replay CLI accept --config.

AI-agent execution notes

• Inspect first: _mcp_cli.py config loader, config.py, profiles.py, context/manager.py constructor, store/ constructors, scripts/gen_schemas.py.
• Security: refuse arbitrary dotted-path class loading from config (document why); paths in config resolved relative to the config file.
• Tests: valid/invalid configs, precedence of explicit kwargs over file values, schema drift gate.

Acceptance criteria

• ContextManager.from_config() constructs a manager equivalent to the documented programmatic setup (equality asserted via to_dict of each config object).
• Invalid config produces a ConfigError naming the failing JSON path.
• Schema committed and covered by make schemas-check; contextweaver init scaffold round-trips through from_config.

Test plan

Unit tests (happy path, each invalid section, kwarg precedence); CLI test for init + build --config; make ci with schemas gate.

Documentation plan

New docs/ configuration page, quickstart link, CHANGELOG, AGENTS.md module map row.

Migration and compatibility notes

Not expected to require migration; the gateway --config format should be referenced and kept compatible where keys overlap (top_k, beam_width).

Risks and tradeoffs

Two sources of truth (code vs file) can drift — define precedence once; schema maintenance is mitigated by the existing drift gate. Alternative (env vars) rejected: poor fit for nested config.

Suggested labels

product, developer-experience, documentation