Keeper Exact-Task Completion Adoption Proposal

Date: 2026-08-25 Portfolio state: adopted; implementation has not started Capability ID: keeper_exact_task_completion_v1 Decision authority: operator Adoption decision: adopted by the operator on 2026-08-25

Operator outcome

Complete one exact, currently observed Keeper task through the canonical durable governed-action lifecycle. The operator can inspect the bound task, review a deterministic proposal, approve or reject it through Lich, separately request execution, and inspect Zeus before/after evidence and the durable receipt after restart.

This proposal is the adopted implementation contract. Adoption authorizes only the bounded implementation described here. It does not approve a task mutation or grant Keeper, Lich, Oracle, Rubick, a transport, or a model new runtime authority.

Repository evidence

Keeper exposes canonical task inspection, completion, and reopen endpoints.
app/keeper/conversation.py resolves visible task references and creates Lich approval requests for keeper.complete_tasks.
app/keeper/execution.py invokes the completion endpoint after approval but returns a capability-local process result rather than the canonical durable proposal, Zeus evidence, and receipt lifecycle.
app/runtime/pending_actions.py provides a separate durable task-creation path, demonstrating both reusable behavior and a lifecycle seam.
The shared governed-action platform already supplies durable proposals, exact approval binding, revalidation, execution brokerage, evidence, receipts, and restart-safe inspection.

These facts establish feasibility, not implementation authority or readiness.

Exact scope

Resolve exactly one task from current Keeper evidence and bind its immutable task ID, title snapshot, current state, and evidence revision.
Create one deterministic durable proposal for the fixed action complete.
Bind one durable Lich approval to the exact proposal hash, task ID, actor, conversation scope, expiry, and Keeper provider identity.
Keep approval and execution separate. Conversational assent does not approve or execute the proposal.
On explicit execution, re-read the exact task and revalidate identity, current state, proposal freshness, approval, provider readiness, and expected revision before mutation.
Invoke only the canonical Keeper completion endpoint for the bound task ID.
Capture normalized Zeus evidence before and after the call and persist a durable execution receipt with a reconciled, refused, failed, uncertain, or completed outcome.
Treat an already-complete exact task as an idempotently reconciled outcome, never as evidence that this execution performed the original mutation.
Expose proposal, approval, evidence, receipt, and restart state through the shared transport-neutral runtime, Runtime Composition, Kernel Records, and operator-friendly rendering.

Non-goals

Batch completion or ambiguous/plural task references.
Waiting, focus, activate, patch, archive, delete, clone, reopen, or task creation behavior.
Objective transitions, scheduling, calendar writes, worker dispatch, or autonomous follow-up.
A new Keeper backend, proposal store, evidence authority, approval system, or transport-specific mutation path.
Automatic execution after approval or automatic compensation.
General refactoring of Keeper conversation, task, or objective systems.

Authority and lifecycle

Keeper remains the canonical task-state authority and sole task mutation provider.
Rubick reports capability and provider posture but grants no authority.
Lich alone records the exact approval decision and does not execute Keeper.
Zeus owns normalized before/after evidence and the durable receipt.
Meepo revalidates the proposal-to-execution transition when the shared lifecycle requires it.
Oracle may report facts, inferences, recommendations, and audit views but may not approve, execute, or mutate.
Luna and all transports normalize intent and render the shared result only.
Models cannot select the capability from quoted, negated, hypothetical, transcript, report, or meta-instructional text.

Portfolio adoption would authorize only implementation of this bounded capability. Every live task completion would still require its own exact Lich approval and separate execution request.

Persistence and restart behavior

The proposal, approval reference, evidence identifiers, transition state, and receipt must use the canonical durable stores. Session continuity may retain a display reference but is never authority. After restart, the runtime must recover from durable lifecycle state and current Keeper truth, reject stale or tampered transitions, and avoid duplicate completion calls.

Evidence and failure semantics

Before evidence must establish the exact task ID, readable title, current non-complete state, provider identity, observation time, and freshness or revision token available from Keeper. After evidence must re-read the same task and positively establish completion.

Fail closed when the task is missing, ambiguous, already changed incompatibly, unreadable, stale, or lacks a stable ID; when Keeper is unavailable; when proposal or approval identity differs; when persistence fails; or when the postcondition cannot be observed. A successful HTTP response without a verified postcondition is uncertain, not completed. No retry may issue a second mutation until exact current state is reconciled.

Evidence and default rendering must avoid unnecessary task notes or other private content. Human-friendly title snapshots may be shown to the scoped operator; diagnostic IDs remain available in diagnostic mode.

Compensation and reversibility

Keeper exposes a reopen endpoint, so task completion has a plausible inverse, but this proposal does not claim automatic rollback. Reopen is a distinct mutation with a different current-state precondition and must require a separate future capability or separately governed compensation proposal.

The completion receipt should therefore classify the action as compensation_available_not_implemented only when current Keeper evidence confirms that the exact task can be reopened. Otherwise it must record the more conservative non-reversible or unknown classification. Adoption of this proposal does not adopt reopen.

Compatibility and migration

Existing Keeper read behavior remains unchanged. Existing approval payloads and KeeperExecutionReceipt may remain temporarily for compatibility, but the canonical route for this exact completion outcome must stop treating them as authority once durable parity is proven. Legacy pending session state must not approve or select execution. Other Keeper mutations remain on their documented legacy paths and must not be presented as consolidated.

No shared platform extension is justified unless implementation proves a correctness requirement serving at least one additional independent capability. Keeper-specific parsing, task evidence, endpoint behavior, and compensation rules stay capability-local.

Acceptance criteria

One exact visible task can produce a deterministic durable proposal without mutation; ambiguous, plural, missing-ID, quoted, negated, and hypothetical requests fail closed.
The proposal hash binds the exact task ID, expected state/revision, fixed completion action, operator scope, provider, expiry, and evidence identity.
Lich approval is durable, exact, scoped, and separate from execution; rejection, expiry, mismatch, and conversational assent never mutate Keeper.
Explicit execution revalidates current Keeper and Rubick evidence before exactly one completion call.
Zeus persists normalized before/after evidence and a canonical durable receipt. Missing postcondition evidence yields an uncertain outcome.
Replay and restart cannot duplicate mutation and can explain the proposal, decision, execution attempt, evidence, and outcome.
Discord, Terminal TUI, and Web TUI reach the same runtime contract and preserve raw diagnostic details only in diagnostic mode.
Runtime Composition and Rubick report implementation, configuration, readiness, reachability, authority, persistence, and evidence without inflating unavailable or unverified posture.
Existing Keeper behaviors remain compatible, and no other transition is represented as consolidated.
Focused tests, the full repository suite, architecture/static/pre-commit checks, strict documentation build, Compose rebuild/health, and acceptance through the deployed Keeper-facing surfaces pass under the repository Definition of Done.

Required test matrix

Deterministic proposal identity and hash sensitivity.
Exact task identity, stale revision, changed state, missing task, and provider-unavailable refusal.
Approval rejection, expiry, actor/scope mismatch, tampering, and duplicate execution refusal.
Successful completion, already-complete reconciliation, provider error, malformed response, persistence failure, and unverifiable postcondition.
Restart at proposal, approved-not-executed, execution-in-progress, uncertain, and completed states.
Kernel Record and Oracle audit linkage without authority leakage.
Transport parity across Discord, Terminal TUI, and Web TUI.
Live Keeper completion on a disposable task and separate cleanup or reopen only under an explicitly governed test procedure.

Risks

The existing approval and pending-action paths can accidentally become a third lifecycle if compatibility is not bounded.
Completion can appear harmless while still hiding stale-reference or duplicate-execution errors.
A reopen endpoint does not prove compensation safety or authorize its use.
Task titles and notes can contain private operator content and require bounded evidence/rendering.
Broadening the first slice to batches or other states would obscure the lifecycle proof and increase partial-failure semantics.

Adoption decision

The operator adopted keeper_exact_task_completion_v1 on 2026-08-25. This authorizes implementation within this contract. The item remains adopted until implementation actually begins, when the roadmap must move it to in_progress. Every runtime task completion remains independently proposal- and Lich-gated.