553ba23b89
Integration of 3 quick wins into existing UOK infrastructure: 1. Model Learning (Quick Win #2) → metrics.js - Record outcomes to model-learner for per-task-type performance tracking - Hook: recordUnitOutcome() now calls ModelLearner.recordOutcome() - Fire-and-forget: never blocks outcome recording on learning failure - Enables adaptive model routing decisions in downstream gates 2. Self-Report Fixing (Quick Win #1) → triage-self-feedback.js - Auto-fix high-confidence reports (>0.85) in applyTriageReport() - Hook: After triage and requirement promotion, apply auto-fixes - Fire-and-forget: never blocks report application on fix failure - Returns reportsAutoFixed count for triage metrics 3. Knowledge Injection (Quick Win #3) → already integrated in auto-prompts.js - Already active in execute-task prompt template - Semantic matching with graceful degradation All integration points: - Fire-and-forget: learning/fixing failures never block dispatch - UOK-native: use existing outcome recording, db, gates - Backward compatible: applyTriageReport now async, but callers handle it - No new dependencies: all modules already in codebase Testing: 2934 tests pass (no regressions from integration) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
25 lines
1.4 KiB
Markdown
25 lines
1.4 KiB
Markdown
# ADR-008: SF Tools Over MCP for Provider Parity
|
|
|
|
**Status:** Rejected — never implement
|
|
**Date:** 2026-04-09
|
|
**Superseded by:** `docs/adr/0000-purpose-to-software-compiler.md`, `docs/dev/ADR-020-internal-wire-architecture.md`
|
|
|
|
## Decision
|
|
|
|
Never build or restore an SF MCP server package. SF is not an MCP server product and must not become one.
|
|
|
|
Current SF uses MCP only as a client-side integration surface for external tools that SF may call. SF workflow execution stays inside the `sf` runtime through in-process extension tools, daemon/RPC/headless paths, and DB-backed workflow state.
|
|
|
|
## Reason
|
|
|
|
The original ADR proposed exposing SF workflow tools through a new MCP server for provider parity. That creates another mutable workflow transport and another state-safety surface. The current architecture avoids that extra server boundary: planning, execution, validation, and completion write structured state to SQLite first and render markdown/JSON as projections.
|
|
|
|
## Operational Rule
|
|
|
|
- Never recreate `packages/mcp-server`.
|
|
- Never add a `src/mcp-server.ts` workflow backend.
|
|
- Never document SF as an MCP server provider.
|
|
- Never add provider-parity work that depends on SF exposing itself over MCP.
|
|
- Keep `src/resources/extensions/mcp-client/` as the client integration boundary.
|
|
|
|
If a future integration needs external control of SF, use the daemon/RPC/headless contract. MCP remains for SF-as-client only.
|