@awak-app/simy-cli 0.5.34 → 0.5.35

package/src/codex-plugins/simy/skills/delivery-loop/SKILL.md

@@ -8,8 +8,8 @@ description: Continue an explicitly requested SIMY Delivery Loop in the current
 Use only when the user explicitly requests this skill or SIMY Delivery Loop for the current task. Installing this plugin does not opt a task in. Do not run SQM unless separately requested.
 
 1. Require the SIMY SessionStart hook context with the exact provider and session ID. If absent, explain how to install the SIMY plugin, review and enable its hooks with `/hooks`, and start a new conversation. Codex settings can be opened at `codex://settings`; a hooks subpage deep link is not guaranteed. Never change hook trust or bypass permissions yourself.
-2. Use `simy delivery start --provider <provider> --session <exact-session-id> --objective '<user outcome and acceptance criteria>' --next-step '<concrete next action>'`. Default limits: 6 automatic continuations, 3 consecutive failures/missing checkpoints, 30 minutes. Set different finite limits only if the user requests them. Use the current working directory. Never invent a session ID, start another loop to reset limits, or resume a stopped loop without a user request.
-3. Work in the current conversation with its normal permissions. Before ending each turn, write a JSON checkpoint and run `simy delivery checkpoint --provider <provider> --session <id> --file <file>` from the same directory. Keep checkpoints outside the tracked source diff.
+2. For a regular Delivery Loop, use `simy delivery start --provider <provider> --session <exact-session-id> --objective '<user outcome and acceptance criteria>' --next-step '<concrete next action>'`. When the user explicitly asks for a managed task with durable acceptance tracking, add `--managed-file <task.json>` as described below. Default limits: 6 automatic continuations, 3 consecutive failures/missing checkpoints, 30 minutes. Set different finite limits only if the user requests them. Use the current working directory. Never invent a session ID, start another loop to reset limits, or resume a stopped loop without a user request.
+3. Work in the current conversation with its normal permissions. Before ending each turn, submit a JSON checkpoint through standard input with `simy delivery checkpoint --provider <provider> --session <id> --file -` (for example, a shell heredoc). This updates SIMY state; it does not require writing a checkpoint file to the user's workspace. A file path remains supported when authorized.
 
 Checkpoint shapes:
 
@@ -26,3 +26,21 @@ For completed work use `{"status":"completed","summary":"Actual result","accepta
 
 4. The Stop hook evaluates checkpoints and supplies the next instruction within the original budgets. Missing checkpoints consume the failure budget. A human interrupt stops the loop. Approval/input events block it. Provider errors/exits may require reopening the existing conversation; these hooks cannot restart a dead provider process.
 5. After the user explicitly resolves the blocker and requests continuation, `simy delivery resume --provider <provider> --session <id>` retains all budgets. `simy delivery stop` permanently ends this loop. `simy delivery status` shows observed hook activity and loop states; old observations do not prove hooks remain enabled today.
+
+If the user selected **Continue this conversation** in SIMY desktop, the exact session already has a managed task. Do not run `delivery start` or ask the user to restate its goal. Follow the Stop hook's distinct `session_understanding` contract first: inspect only the original conversation context, report the original user goal and grounded progress, and submit the JSON checkpoint via `--file -`. Do not execute the next assessed work action during understanding. If context is materially unclear, report one focused question and wait for a matching `session_answer`; generic Resume is insufficient. A model-reported finished goal without an independent check is shown as `reported_done`, not verified `completed`.
+
+For an explicitly enrolled managed task (`--managed-file`), keep its task ID and frozen acceptance criteria. Every `in_progress` or `error` checkpoint must include a concrete `proposedAction` with `kind`, `scope`, and `summary`, plus `remainingWork` when known. Allowed kinds are `read`, `local_edit`, `local_test`, `external`, `destructive`, `scope_change`, and `unknown`. Record an authorization blocker with the proposed next step and a scoped `approval` object; do not assert that a provider permission has been granted by a SIMY policy. A `completed` checkpoint with worker evidence may remain `verification_pending` until the local verifier or user confirms every criterion. Do not mark a manual criterion verified on the user's behalf.
+
+The managed file must include `initialAction` and nonempty `acceptanceCriteria`. Use only criteria the user actually agreed to, such as:
+
+```json
+{"actionId":"ACTION-123","actionDueAt":"2026-10-05T09:00:00+09:00","initialAction":{"kind":"local_edit","scope":"repository","summary":"Implement the requested parser"},"approvalPolicy":"wait","approvalScopes":[],"acceptanceCriteria":[{"id":"output","description":"Expected output is exactly READY","check":{"type":"file_equals","path":"output.txt","text":"READY"}},{"id":"review","description":"User accepts behavior","check":{"type":"manual"}}]}
+```
+
+File checks prove only the stated file predicate: `file_equals` compares complete UTF-8 bytes including whitespace, `file_contains` proves a substring, and `file_exists` proves existence. Tests, deployment, and subjective acceptance need explicit user verification. The user can verify each manual criterion from SIMY desktop or `simy delivery verify --provider ... --session ... --task-id ... --criterion-id ...`. `approvalPolicy` is `wait`, `automatic`, or `proceed_and_report`; the last two apply only to enrolled scopes for `read`, `local_edit`, and `local_test`. External, destructive, changed-scope, and unknown actions always wait for an exact proposal decision. SIMY approval does not change provider permissions. Rejected proposals remain blocked until the user revises or stops the task.
+
+Cold recovery is **off by default**. Only when the user explicitly authorizes exact-session Codex CLI recovery, add `"autoRecovery":true,"resumeChannel":"codex_exec","resumeModel":"<exact model>","autoRecoverySandbox":"read-only"` (or an explicitly authorized `workspace-write`). An exact Codex UUID and observed process identity are also required; otherwise recovery stays manual. The recovered process returns a structured final checkpoint that SIMY validates and persists. It must not edit SIMY state directly. Claude and ordinary SessionEnd remain manual paths. Token usage is not measured by these hooks.
+
+For an explicitly requested autonomous managed task, also enroll `"autonomyPolicy":"strict"|"balanced"|"autonomous"` and an `initialPlan` before work begins. Example initialPlan: `{"diagnosis":"Inspect input before repair","alternatives":[{"id":"inspect","action":{"kind":"read","scope":"repository","summary":"Inspect input.json"},"assessment":{"risk":"low","reversibility":"reversible","externalEffect":"none","blastRadius":"single_file","uncertainty":"low","inObjective":true,"userChoice":false},"expectedVerification":"Observe ready field","rollback":"No changes"}],"selectedOptionId":"inspect","recommendation":{"optionId":"inspect","reason":"Need evidence before editing"}}`. `initialAction` must exactly match the selected option and its scope must be enrolled in `approvalScopes`. For each subsequent action, report `actionResult:{decisionId,status:"observed"|"failed"|"not_run",summary,evidence}` for the current decision and a `plan` with diagnosis, one to five assessed alternatives, selectedOptionId, and recommendation for the **next** action. Never execute the next alternative in the current turn. Use only action kinds `read`, `local_edit`, `local_test`, `external`, `destructive`, `scope_change`, `unknown`; use `local_edit` for writing local files. Missing assessment facts, external/destructive effects, user choice, or unapproved scope wait. A recommendation is advisory, not an authorization. Worker reports are not independent acceptance verification. If an automatic file criterion is missing after claimed completion, SIMY schedules bounded read-only diagnosis; manual criteria still require the user. Task policy can be changed with `simy delivery set_policy --provider ... --session ... --task-id ... --autonomy-policy strict|balanced|autonomous`, which preserves budgets and scopes. Provider permissions remain authoritative.
+
+In assessed mode, a blocked authorization checkpoint must also include an assessed `plan` whose selected action exactly matches `approval:{kind,scope,summary}` and a concrete `nextStep`. A missing-information blocker must include a specific `question` for the user. Do not turn a provider approval prompt into an automatic scheduling grant, even for a normally low-risk action. Resume only after the exact user decision; low-risk enrolled actions already allowed by the policy do not need an additional SIMY approval.