singularity/singularity-forge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
singularity-forge/docs/dev/ADR-008-sf-tools-over-mcp-for-provider-parity.md
Mikael Hugo 553ba23b89 integrate: hook quick wins into UOK dispatch loop 
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>
2026-05-06 22:34:41 +02:00

1.4 KiB
Raw Blame History

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.