refactor(mcp)!: remove remaining order integration artifacts

Remove order compatibility fields, routing notices and migration references
from Wiki source, skills and documentation. Bump capability schema to v6
and validate the remaining Wiki query response contract.

Move retired runtime configuration, database and completed job archives to
the independent order project, uninstall legacy units and clear stale
bytecode. Keep Git history for provenance.

Validation: 173 Wiki tests pass; live independent order MCP authentication,
queries and write rejection pass after cleanup. No integration filenames,
config keys or source references remain in the Wiki working tree.

BREAKING CHANGE: query results and capability metadata no longer contain
legacy business-related fields. Wiki consumers must use the v6 schema.
This commit is contained in:
Codex
2026-10-31 10:25:32 +00:00
parent 2396bd2d3e
commit 1dd5d8d753
11 changed files with 13 additions and 57 deletions
-9
View File
@@ -1,9 +0,0 @@
# Order service extraction
Order MCP and Kingdee synchronization now live in the independent project at `/home/nac/repo/kingdee-orders-mcp`. Its README documents CLI operations, MCP configuration, and systemd services. Neither project imports the other.
The new project owns `.runtime/data/business-facts.sqlite`, private API credentials, token cache, and its daily incremental sync. MCP clients retain the existing URL and bearer token. The order tool names are unchanged. Wiki query, file lookup, and ingest are not exposed by the order server.
The former `obsidian-wiki-mcp.service` and `obsidian-wiki-business-sync.timer` are disabled. The old vault `_meta/business-facts.sqlite` and private runtime configuration are retained as rollback backups, not active data sources. Do not run the old sync against this backup.
For rollback, stop the new MCP and sync timer first. Restore Wiki code from commit `6c451c3` (prefer an isolated checkout), restore its private service environment from the migration backup, and point the legacy service at a consistent backup of the latest new database before enabling it. Do not resume the stale original database silently. Ensure only one sync owns the live database. New credentials and databases must never be committed to Git.