Runtime-authorized recovery decision for known gaps (0.3.0) #642

Problem

Collection Profile 0.2.0 (Sections 5.5 and 5.11) treats a connector's own hint and text as a claim. After #636 the runtime no longer acts on a connector's retryable flag, recovery hint or message. Two classifiers still infer retry and owner-recoverability from text:

• server/connector-gap-classification.ts:51-80: gapClassifierText joins a gap's kind, reason and message, and isOwnerRecoverableKnownGap matches keywords (OTP, MFA, captcha, manual) in it. The gap message comes from the connector.
• runtime/scheduler-retry-classifier.ts:70-72, :88-90, :116: a regular expression over failure_reason decides owner auth repair. classifyRuntimeFailure (runtime/classify-runtime-failure.ts:22-40) derives that reason from error message strings when no explicit reason is set.

So "retry" and "the owner can fix this" are still inferred from message text. A connector can steer both by wording.

Proposal

For 0.3.0, add one runtime-authorized recovery decision per gap: an action (retry, owner action, none), made only from evidence the runtime holds itself (its own failure classification, a recorded interaction, a provider-invalidation proof). Store it on the gap together with its provenance (which rule or proof produced it). The connection-health projection and the scheduler's retry classifier both read that stored decision, and neither reads gap text.

Not verified

I have not measured how many existing connector gaps would change classification, or whether any shipped connector relies on the current keyword match.

Assisted-by: AI