[abrichr]

This PR implements the coordinator's decision on the problems_only switch policy: classify every problem, and let a person re-arm only with a signed tap. It is stacked on OpenAdaptAI/OpenAdapt#1514.

Why: in the measured soak (OpenAdaptAI/OpenAdapt#1513), one caught problem turned the switch off for the rest of the run. Every later save then needed an approval: 25 of 125.5 operator minutes.

1. Which problems turn it off (post.problem_class, classify_decision)

Item-input problems leave the switch on. The item goes to a person and doesn't count toward too_many_problems. These are problems caught before anything was written:

• a value refused before the first step: a missing required value, or an invalid typed value such as a non-ISO date;
• an input item check (inputs_supplied, inputs_strict, channel);
• a real candidate in the app's duplicate list. This is read from the duplicate check's structured outcome, StepResult.duplicate_check == "candidate", which the record-channel check in Duplicate check asks the system of record (FHIR/REST, SQL fallback) instead of the screen list #1516 sets. It is never read from the error text. An unreadable list or channel ("unreadable") turns the switch off with record_check_lost. Until Duplicate check asks the system of record (FHIR/REST, SQL fallback) instead of the screen list #1516 sets the field, a duplicate stop is a program problem.

Program and environment problems turn it off at once. For example:

• a wrong write the record check caught;
• a failed identity check;
• a postcondition that failed after delivery;
• a changed screen;
• the wrong signed-in user;
• any unnamed cause.

Any outcome that doesn't consistently read "nothing was written" is a program problem (fail closed). A switch-off the gate, R2 or the engine already named is never classed down to an input problem. Gate pre-check failures map to closed off reasons: signed_in_user → environment_changed, right_record and same_screens → screen_changed, record_check_ready → record_check_lost. too_many_problems stays as a backstop.

2. A person re-arms with one signed tap (switch.rearm_request, sign_rearm, rearm)

• Never automatic, under any profile.
• Offered only after 10 consecutive verified items since the switch went off. These are no_person or approved items; any other finished item resets the count.
• What the person's approver key signs: the off event and its reason, the recorded cause, and those 10 run refs.
• What the log records: a rearmed event with who signed, the key, and what they saw. The field is left out of every other event, so existing log lines and hashes are unchanged.
• Who honours it: a gate that trusts the signing key. By default, and deliberately, those are the approvers registered in the JIT key directory's principal registry. A person registers each at a terminal (jit register --role approver, fix: a person's approval needs a registered approver key's signature #1486), and the registry refuses agent and model names. ApprovalGate(pinned_approver_keys=...) names keys explicitly instead. Keys may be hex (the registry's form) or base64.
• Binding: a re-arm's approver_id must equal its key_id (the key's registered name).
• Only a verified re-arm ends an off period. Every reader checks the re-arm again against the log before it, so a forged, tampered, replayed or early re-arm appended to the log is ignored and doesn't reset the count.
• Signing outside Python: rearm_to_sign returns the exact bytes, and rearm_evidence wraps a signature made elsewhere. Desktop's Touch ID card (feat(desktop): 0.24.0, the Touch ID approver key and one-tap stop review #1519) uses these.
• Before fix: a person's approval needs a registered approver key's signature #1486 lands, main's registry has no approvers, so no re-arm counts.

3. A bug the soak exposed

_unapproved_delivered_saves classified saves without the certifying policy, as the gate's own save check did before #1455. On OpenEMR, "Create New Patient" (certified as not saving) counted as an unapproved delivered save. So after the switch turned off, every approved, verified item was logged as a problem (save_not_approved), and it could never have counted toward a re-arm.

Tests

• New test_approval_mode_switch_policy.py (23). Covers:
  • review cases: an explicit switch-off with an input-class halt stays off; a duplicate stop counts as input only from its structured outcome, and an unreadable one turns it off; a replayed old re-arm after a second switch-off; a re-arm for another switch log; a forged re-arm, then a real one; a mismatched approver; the gate reading on after a valid re-arm, and a gate that doesn't trust the key reading off;
  • registry keys in hex; an unreadable registry gives no keys; signing with a key that never leaves its keychain;
  • an invalid date, a missing value and a duplicate candidate leave the switch on;
  • a caught wrong write turns it off (uncertain_result);
  • an unnamed stop before any effect turns it off;
  • a duplicate stop after a delivered save, or an inconsistent outcome, is a program problem;
  • re-arm: signed after 10 verified items turns it on;
  • refused before 10, or after a problem resets the count;
  • refused unsigned, with an unpinned key, tampered, or forged;
  • fifteen clean items alone change nothing;
  • a later problem turns it off again;
  • a forged rearmed event appended to the log is ignored.
• Old-policy tests updated (4). They expected a counted problem without a switch-off, or three in a row before one.
• Locally: every test that touches the switch log or approval modes passed (797 in 32 files); after the review fixes, the approval-mode suites pass (360), and ruff and mypy pass.

🤖 Generated with Claude Code