[Marc-cn]

Summary

darnit serve with no --framework serves whichever installed framework sorts first by name. cmd_serve takes frameworks[0] from list_available_frameworks(), which returns a sorted list.

On a full darnit-mcp install the list is gittuf, openssf-baseline, reproducibility, so the server starts with gittuf:

$ darnit serve
INFO: Starting MCP server with framework: gittuf

darnit install registers uvx --from darnit-mcp darnit serve, with no framework. So a client set up the documented way gets the gittuf tools and no OpenSSF Baseline tools. From a source checkout with every workspace plugin, the first name is community-spec; that is how I found it reporting that only the CSL audit tool was available.

darnit audit already has a different rule: load_effective_config_auto defaults to openssf-baseline. This makes serve follow the same default:

1. openssf-baseline, if it is installed (and allowed by the operator configuration).
2. Otherwise the only installed framework, if there is exactly one.
3. Otherwise an error that lists the installed frameworks and asks for --framework.

Changes: a small _default_framework helper in cli.py, the two help strings that said "auto-detect", tests, and a CHANGELOG entry.

Type of Change

• Bug fix (non-breaking change fixing an issue)
• New feature (non-breaking change adding functionality)
• Breaking change (fix or feature causing existing functionality to change)
• Documentation update
• Refactoring (no functional changes)

One case does change behavior and may deserve the "breaking" box, your call: with several frameworks installed and no baseline, serve used to pick the first by name and now exits 1 asking for --framework.

Framework Changes Checklist

• Updated framework spec (docs/architecture/framework-design.md) if behavior changed (I did not find the serve default described there; say if it belongs)
• Ran uv run python scripts/validate_sync.py --verbose and it passes

Testing

• Tests pass locally (uv run pytest tests/ -v): 5144 passed, 26 skipped (main: 5138)
• Added tests for new functionality (if applicable)
• Linting passes (uv run ruff check .)

Six test cases in tests/darnit/test_cli.py: four for the helper, and two that run main(["serve"]) with a fake framework list and a fake server. The two serve tests fail without the fix. Nothing tested the default before.

By hand, starting the real server with stdin closed:

Install	Before	After
The five darnit-mcp wheels in a clean venv	gittuf	not re-run on wheels; covered by the unit test with the same list
Workspace, eight frameworks	community-spec (seen in Claude Code)	openssf-baseline

AI assistance

• No AI assistance was used
• AI assistance was used

Claude Fable 5.1 wrote the helper, the tests and the help-text changes, and drafted this description. I ran every command and checked the results myself. The commit carries an Assisted-by: Claude:claude-fable-5-1 trailer.

Additional Notes

• I have not installed the 0.1.0 that is on PyPI, so I do not know which framework it serves. The claim above is about anything built from current main.
• feat(cli): add darnit install --from-source #571 registers serve --framework openssf-baseline for source installs and has a code comment saying serve takes the first framework it finds. Naming the framework stays correct after this PR; the comment should be updated in whichever of the two merges second.

[mlieberman85]

Thanks, confirmed: built darnit-mcp wheels served gittuf on main and serve openssf-baseline with this PR, and the "several installed" refusal works with plugins.allowed.

1. darnit install still writes uvx --from darnit-mcp darnit serve with no framework (cli.py:694). uvx runs the PyPI release, and 0.1.x still takes frameworks[0], so clients set up the documented way get gittuf until the next release. Could you add "--framework", "openssf-baseline" there (as #571 does for --from-source)? Then W-31 is fixed regardless of version. Happy for it to go in #571 instead if that lands first.
2. Small: cmd_serve's docstring and the "Legacy mode: Auto-detect" comment are stale; could DEFAULT_FRAMEWORK be shared with load_effective_config_auto so the two defaults can't drift; and the error could say "installed and allowed" when plugins.allowed narrowed the list.

Drafted with Claude Code; reviewed and posted by me.

[Marc-cn]

Rebased onto main after #582 merged. The only conflict was the CHANGELOG entry, and nothing else changed. Merging on your approval once CI is green. Your point 1 (plain darnit install passing --framework) goes into #571, and the small ones into a follow-up.