|
| 1 | +# Canonical terminal review and validation |
| 2 | + |
| 3 | +On an explicitly promoted local Goal, Agent completion and Monitor stop now use |
| 4 | +the same reviewed recovery path as Todo edits and User completion. The initiating |
| 5 | +Chat action binds the complete provider revision and registry digest, preserves |
| 6 | +one operation identity, and acknowledges display only after the existing |
| 7 | +projection outbox confirms the current view. |
| 8 | + |
| 9 | +## Operate and recover |
| 10 | + |
| 11 | +For ordinary CLI completion, retain the same explicit completion identity after |
| 12 | +a lost response: |
| 13 | + |
| 14 | +```bash |
| 15 | +loopx todo complete --goal-id example-goal --todo-id todo_work \ |
| 16 | + --agent-id agent-a --completion-identity-key reviewed-result --no-follow-up |
| 17 | +loopx todo list --goal-id example-goal --todo-id todo_work |
| 18 | +loopx todo project-markdown --goal-id example-goal --execute |
| 19 | +``` |
| 20 | + |
| 21 | +Use `--no-follow-up` only when no successor is needed. Leased work additionally |
| 22 | +requires its current `--task-lease-idempotency-key` and |
| 23 | +`--task-lease-expected-version`; owner confirmation is not a lease or a lifecycle |
| 24 | +grant. Chat users retry the same failed proposal. A stale proposal requires a |
| 25 | +fresh preview, not a replacement identity that bypasses review. |
| 26 | + |
| 27 | +| Boundary | Observable result | |
| 28 | +| --- | --- | |
| 29 | +| Provider/registration changes before a fresh reviewed completion | Reject before private validation execution; Chat marks the proposal stale | |
| 30 | +| Provider changes during validation | Reject the old validation result; Todo remains unfinished | |
| 31 | +| Lease expires during validation | Recheck runtime time and reject stale execution proof | |
| 32 | +| Canonical commit succeeds, display delivery fails | Business remains committed; Chat reports recoverable failure without a successful display receipt | |
| 33 | +| Response/action receipt is lost after commit | Retry recovers the original business receipt before checking current review freshness | |
| 34 | +| Same operation carries a changed reviewed note, evidence, reason or basis | Reject identity reuse; never silently acknowledge the changed intent | |
| 35 | +| Private declaration is unavailable after successful completion | Business receipt can recover from its public commitment; lossless display recovery still requires restoring the original declaration | |
| 36 | + |
| 37 | +The TypeScript terminal owner performs admission, source checks, validation |
| 38 | +planning, lease retirement, linked effects, CAS and receipt recovery. Python |
| 39 | +transports facts, resolves private argv only when requested, executes declared |
| 40 | +validation and drains projection. It does not decide whether a stale validation |
| 41 | +can complete work. The preview executes no validator. Separate user-completion |
| 42 | +edits retain their existing combined edit/terminal semantics and old stored Chat |
| 43 | +proposals retain their existing protocol. |
| 44 | + |
| 45 | +## Wire and migration boundary |
| 46 | + |
| 47 | +The current Python terminal adapter sends |
| 48 | +`loopx_local_coordination_todo_terminal_lifecycle_request_v2`. The existing |
| 49 | +terminal method accepts these bounded additions: |
| 50 | + |
| 51 | +- `review_basis`, when present, contains exactly `provider_revision` and |
| 52 | + `registry_sha256`. It binds reviewed intent and is part of receipt identity. |
| 53 | +- `validation_source_provider_revision` is null before an issued effect and is |
| 54 | + the returned revision on continuation. It is a freshness constraint, not new |
| 55 | + operation identity. Both caller validation and Goal acceptance validation |
| 56 | + require it in v2. |
| 57 | +- `validation_declaration_sha256` carries the canonical public commitment. |
| 58 | + Historical recovery precedes private declaration resolution. Fresh execution |
| 59 | + still requires the matching declaration and current authorization. |
| 60 | + |
| 61 | +The existing method may return `resolve_validation` before `execute_validation`. |
| 62 | +Both responses bind the source revision; neither commits the business operation. |
| 63 | +For a validated fresh completion the host crosses the runtime boundary three |
| 64 | +times (resolve, plan effects, commit), versus two before this change. Unvalidated |
| 65 | +completion and historical recovery remain one terminal request. This bounded |
| 66 | +extra crossing makes receipt recovery independent of host-local argv; it can |
| 67 | +disappear when the native host owns declaration resolution and effect execution. |
| 68 | + |
| 69 | +v0/v1 retain their old request fingerprints and validation contract. They reject |
| 70 | +the new fields rather than silently discarding obligations. A v2 request without |
| 71 | +review preserves the existing CLI terminal fingerprint. Existing receipts are |
| 72 | +not rewritten. The public completion facade rejects a reviewed canonical request |
| 73 | +if authority has reverted to an unpromoted legacy path. |
| 74 | + |
| 75 | +No provider default, promotion, permission, retention or storage format changes. |
| 76 | +Rollback restores compatible code while retaining provider data, receipts and |
| 77 | +writer fences. Older code cannot execute v2; regenerate a preview with compatible |
| 78 | +code instead of stripping its review fields. Markdown stays a permanent display. |
| 79 | +These changes close the terminal review/recovery family, not all leased metadata |
| 80 | +updates, executor-held external-effect fencing, D1–D3 or whole-Goal cutover. |
| 81 | + |
| 82 | +Shared provider conformance uses the complete production-scale fixture, both |
| 83 | +native and imported records, stale review/validation, expired proof, lost commit |
| 84 | +response and unchanged non-target state. Real File/SQLite Chat HTTP tests exercise |
| 85 | +the packaged entrypoint and retry feedback. The frontend runtime decoder and shared action-review plan now recognize the |
| 86 | +terminal basis for exactly Agent completion and Monitor stop. The packaged Chat |
| 87 | +bundle includes the original-operation retry path and distinguishes pending |
| 88 | +display from verified completion; no new configuration or visual control is required. Lark receives no new |
| 89 | +command or transport in this slice. |
0 commit comments