Skip to content

person provider: add in-place set and structured negotiation errors #743

Description

@wesm

Two small gaps that make person provider awkward for agents to drive. They are independent and can land separately.

1. No in-place edit

person provider add refuses an existing name and there is no set command. Because reasoning_effort, output_mode, and token_limit_parameter are part of the fingerprint, every tuning change is:

remove -> add (with network check) -> consent -> use -> daemon restart

Proposal: person provider set <name> --reasoning-effort high ... that rewrites the profile in place, re-runs the synthetic check, and revokes the old consent. That preserves the "any edit needs a fresh check and consent" rule while cutting the cycle to set -> consent -> restart.

2. Negotiation errors are opaque

ProviderError keeps the HTTP status and request id, but CapabilityChecker.Negotiate (internal/peoplesweep/capability_check.go) collapses every failure to "provider capability negotiation failed". A wrong model name and a rejected parameter look the same.

The classifier in internal/peoplesweep/http_driver.go already parses bounded structured fields (code, type, param for OpenAI and Anthropic, reason and parameter for Google) to decide whether to fall back. Proposal: carry those fields, plus status and request id, on the returned error. Free-text provider messages stay excluded so nothing from the response body is echoed.

Context

Raised in the #694 review.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions