Phase 3: add bounded self-only human caregiver live bridge

[yo4e]

Summary

Implements #158 as the first bounded live-human capability candidate for Human Caregiver Pilot v1.

This candidate is intentionally self-only and local/manual. It does not contact ChatGPT/OpenAI APIs, any model provider, network service, subprocess, browser, credential store, filesystem transport, or external mutable writer.

Ethics / consent scope

The project owner explicitly approved Pilot v1, chose themself as the sole caregiver, and authorized this implementation. #158 records the narrow NOT_REQUIRED_DECLARED ethics context for this one personal self-only hobby-research operational pilot. That determination is not a blanket exemption and must be re-evaluated before involving any other person or institution-affiliated human-participant study.

Implementation

• exact one-shot authorization is fixed to attempt:self-human-pilot-v1-001 and one closed pseudonymous caregiver identity;
• authorization remains bound to Issue Phase 3 live scope: self-only Human Caregiver Pilot v1 bridge #158, a fixed consent-notice version, owner-as-caregiver, self-only scope, NOT_REQUIRED_DECLARED, no raw-chat transcript, no public raw-payload default, 365-day retention, and zero third-party participants;
• process-authoritative attempt state is started exactly once and guarded by a lock;
• each accepted transition increments an authoritative generation and atomically advances cumulative consultation/clarification/time and accepted request/proposal lineage;
• caller-supplied fresh, stale, or forked snapshots cannot advance the attempt;
• request/proposal replay and forged clarification-parent history fail closed;
• disablement is terminal against both the current disabled state and retained stale enabled snapshots;
• rejected submissions do not advance authoritative state;
• human input remains ProposalAuthority.PROPOSAL_ONLY;
• the generic ACTIVE_SOURCE_KINDS remains fixture-only, and a dedicated bridge accepts a human proposal only when the generic validator's sole source-level objection is exactly proposal.live_source_not_authorized;
• no direct action execution, writer authority, model calls, or monetary/model accounting path is exposed.

Fixed Pilot v1 limits

• 1 attempt;
• max 3 consultations;
• max 2 clarifications;
• max 10 minutes caregiver-active time;
• max 5 minutes response latency;
• max 30 minutes attempt wall time;
• max 2,048 UTF-8 bytes per proposal;
• zero off-channel semantic assistance and zero in-attempt manual code edits;
• no personal/secrets/third-party confidential content.

Independent-audit repair batch

Independent audit comment 5467877732 on Issue #161 found two material defects in prior exact head bb0639796a91a500fe1de9f102b5e837201ee258:

1. blocker — caller-supplied state could be freshly recreated, forked, or reused after disablement;
2. high — the authorization factory could mint multiple attempt/caregiver identities.

Both findings and their adjacent replay/clarification/disablement cases were repaired together in one coherent batch. New adversarial regressions cover second start, fresh-state reset, stale/forked reuse, stale post-disable reuse, forged well-shaped lineage, clarification-parent provenance, rejected-submission non-advancement, exact one-attempt/caregiver authorization, fixed budgets, privacy, and generic-validator containment.

Exact repaired green candidate

• head: 74966468a8672b123c3440dbebb6cc008ed08c9f;
• base: 8d17cb3ed2f4fc4b8800dcdfe8839853a904ec06;
• changed files: exactly 3;
• Test run 733 / workflow 33305237822: success;
• 495 passed in 57.64s;
• install: passed;
• source/test compilation: passed;
• protected-output artifact upload: passed;
• schema-v1 genesis CLI smoke: passed;
• artifact ID: 9730247535.

Closure gate

Issue #161 remains the one bounded independent live-capability gate. Because the repair changes the exact attempt-state/authorization boundary identified by the audit, perform one focused closure audit on exact head 74966468a8672b123c3440dbebb6cc008ed08c9f before merge.

The closure review should verify Findings 1 and 2 are resolved and that the previously passing authority/privacy/no-external-I/O/generic-validator boundaries did not regress. It does not need a new full-project audit.

A positive closure conclusion authorizes only merge of this self-only local/manual bridge. It does not freeze Phase 3, authorize another human participant, or authorize any model/provider route.

Refs #161, #158, #3, #157.