You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(install): honor frontmatter provider with flag > frontmatter > default precedence (fixes#414) (#431)
`cao install <profile.md>` silently ignored the profile's frontmatter
`provider:` key: the Click --provider option defaulted to kiro_cli and
install_service.install_agent branched on that argument alone, so a
profile declaring `provider: codex` installed as a kiro_cli agent with
exit 0 and no warning. Install was the only entry point ignoring
frontmatter — launch/assign/handoff already resolve it via
resolve_provider().
The install provider now resolves with the same precedence as the
launch paths: explicit --provider flag > frontmatter `provider:` >
DEFAULT_PROVIDER.
- CLI: --provider defaults to None; help text documents the precedence;
the summary line echoes the provider the service actually resolved.
- install_service.install_agent: accepts provider=None; explicit bad
providers still fail fast BEFORE any URL download or env mutation;
a bogus frontmatter provider logs a warning (same wording as
resolve_provider) and falls back to the default. InstallResult gains
a `provider` field carrying the resolved winner.
- API: InstallAgentProfileRequest.provider defaults to None.
- ops-MCP install_profile: provider defaults to None and is omitted
from the request body when not explicit, so all three entry points
behave identically. Built-in store profiles carry no frontmatter
provider and keep today's default-provider behavior.
Test matrix: flag wins over frontmatter; frontmatter wins when the flag
is absent; both absent -> DEFAULT_PROVIDER; invalid frontmatter provider
warns and falls back; explicit invalid --provider fails before download;
built-in (no frontmatter) keeps the default; API and ops-MCP forward
None for frontmatter resolution.
Co-authored-by: haofeif <56006724+haofeif@users.noreply.github.com>
- clear the `py/clear-text-storage-sensitive-data` CodeQL false positive (code-scanning alert #142) by renaming the local `secret` fixture variable in two `memory_service` secret-gate tests to `gated_content`. CodeQL's name-based heuristic classified the variable named `secret` as a sensitive-data source and traced it into the memory-wiki write (an intentionally plaintext, by-design markdown sink). The literal is the canonical AWS documentation example key, not a real credential; the value and all assertions are unchanged, so the federated secret-gate rejection and global-scope allow paths are still exercised exactly. No production behavior change
0 commit comments