v0.27.0

Added

• Ops history: expected effects, auto-linked decisions and evaluation
  tables (#848, phase 1). Every change can now carry the effect it is
  expected to have, is linked to the decision behind it, and is evaluated
  against that expectation. See docs/ops-history.md.
  • expected (an array of {metric, direction, target?, horizon_days?},
    with directions up / down / hold) is a new optional field on
    mureo_decision_record and on decision records in STATE.json.
  • Every mutating tool now takes optional expected and decision_id
    parameters, alongside reason. A successful call with a reason and
    no decision_id is linked to exactly one decision: its batch's, else
    a new adopted record with a title derived from the change. This
    holds whether or not the call writes an action_log entry; for one
    that does not (such as a native budget update) the decision is
    recorded right after the call. A change is never joined to an earlier
    decision by similarity; an entry later appended for such a call joins
    its decision only on an exact match of session, tool and target ids. A call or batch writing
    several entries shares one decision. A decision_id names a
    proposed or adopted decision to carry out, and a proposed one is
    adopted. mureo_state_action_log_append accepts entry.expected and
    entry.decision_id to the same effect. mureo_decision_record and the
    shared skill now record a proposal only when proposing first; an
    approval is the change-making call naming the proposal's
    decision_id.
  • action_log entries and decisions mureo writes for a call carry
    applied_params, the masked parameters the call sent; decisions also
    carry journal_call_id (and journal_tool for a call that wrote no
    entry), and the call's JOURNAL.jsonl record carries
    call_id and decision_id. Expected metrics match long names
    (cost_per_conversion -> cpa, conversion_rate -> cvr, ...).
  • On the mutating tools, expected is advertised without an item schema
    (its description states the shape and vocabulary), adding about 30 KB
    to the tool list rather than about 80 KB. Items are validated on the
    server as before.
  • The automatic observation closure stores an evaluation table on each
    outcome_evaluated entry: overall, basis, noise_pct, window,
    and per metric before / after / delta_pct / verdict / note /
    role. The decision's expected metrics are primary and decide the
    verdict. Every other metric is kept as reference. The entry inherits
    the decision_id.
  • New workspace setting settings.ops_history.enabled, off by default.
    Turn it on with the new mureo_state_settings_set tool or from
    mureo configure → Advanced → Ops history; only mureo configure turns
    it off. When it is on, a mutating call without reason or expected
    is refused with invalid_args naming the missing parameter, a
    proposed or adopted decision must declare expected, and a call
    naming a decision_id needs expected on the call or the decision. A
    STATE.json that cannot be read counts as off (the call is not
    blocked, but a decision_id is refused).
  • mureo_history_query gains two sources: decisions and ops_history.
    Both return each decision with its changes, their before and after
    values and evaluation, and a derived state (proposed / adopted / executed /
    observing / evaluated / skipped / rejected / deferred) plus a
    rolled_back flag. ops_history also includes the changes that no
    decision covers. mureo.web.reports.build_ops_history(client, since, until) returns the same items for a custom view.
  • Backward compatible: every new field is optional. A STATE.json written
    before this release reads and writes unchanged, and with the setting
    off no call is refused that was accepted before.
• Ops history on the dashboard (#849, phase 2). While the setting is
  on, a client's detail view shows an Ops history section below the recent
  actions: one row per change with its primary metric before and after and
  its verdict, regressed changes first, filters for period, platform,
  state and verdict, and each row expanding into its rationale, expected
  effects, operations and evaluation table. A rationale shorter than 20
  characters is marked "weak rationale". The section reads the new
  GET /api/reports/ops-history?client=&since=&until= (last 30 days by
  default). Where a client registry supplies the clients, each summary
  carries an ops_history count for the last 30 days, shown as one line on
  the client card, and a client with a regressed change that was not
  rolled back raises an attention finding in the triage list. The shared
  skill and
  /daily-check now ask for reason and expected on every change and
  for expected in every proposal. See docs/ops-history.md.